In a bit of a transitive target API pickle here: ...
# development
In a bit of a transitive target API pickle here: If we have a field that can has an "impact" (side effect, I guess?) on transitive targets, where should that field be placed? I've run into these scenarios before, but can't find any examples, so I'll contrive a trivial, fake example while I try to find a precise use case from my archives: Let's say I have a compilation flag that could validly be different per target sources, BUT, when we want to link the compiled sources into a library object, the library requires that all dependencies have the same compiler flag. Is that something where we'd just expect the user to understand the language enough to reconcile that problem? Or would we try to solve it ourself? Or maybe this is where
come in?
Copy code
# In order for check to pass, we need some special compile options
    compile_options=["magicoption1", "magicoption2"]

    compile_options=["magicoption2", "magicoption3"]

// In order for this library to be built, it requires a certain compile option in all deps
    dependencies=[":foo", ":bar"],
    compile_options??? overrides? 
Some of these cases are pretty stupid, and mostly relate to importing 3rd party libs as well - but the question is mostly around how should Pants handle this? In other build systems, normally you just spit out the error and let the developer solve the problem
The similarly shaped thing in Pants today is resolves. To build a binary, its transitive dependencies need to all be part of its resolve, if not, error.
👍 1
So, maybe poke around in that code.
👍 2
+1 on resolves. Stu and I put a lot of thought into the theory and implementation of resolves -- let me know if it'd help to VC about, or share more
👍 1