Question about dep inference (or maybe just common sense in general): I have a C/C++ header here: https://github.com/sureshjoshi/pants-plugins/tree/76-cc-compilation/examples/cc/core/include/core - which is pulled in from another code module in that repo. If I'm compiling

examples/cc/core/src/greeter.c

- the

cc

backend knows how to discover the associated public header (via some dep inference rules, using a common C++ convention). However, if I'm discovering that public header from another module (e.g. the "app" module), it discovers the header file correctly, but from the header, the dep inference doesn't currently know that is has to compile the associated C/C++ source file to actually be useful (nor does there necessarily need to be an associated source file, for a given header). I guess what I'm asking is whether dep inference should be something that is more "targeted" in nature (we need exactly this header, so try to figure out which are the associated source files), or if it should follow a kitchen sink approach (find a source root, enumerate ALL source files and headers below that, mash it all together, and try to make something useful)? The "easy" solution which I already have is to ensure the "app" module has an explicit dependency on the "core"

cc_library

target, which knows how to package the library and public headers correctly. That feels like a cop-out, since compiling dependencies from source is a valid workflow.

So the question is, what should the target of the inferred dep be if some code has

#include path/to/greeter.h

?

Exactly - it gets kinda nutty. cmake basically solves this by forcing explicit specification on everything, which, whatever 🤷 A reasonable approach, to me, seems like looking for the source root's

cc_library

targets, and pulling that in. But, it already doesn't account for a whole host of workflows I think (even some of my workflows own, for that matter, between test and production code). I could probably make the argument that if there isn't a

cc_library

, this could be a use case for a synthetic target? Might not be needed though.

My point is that in c/c++ land we have to be careful about what we mean by “dependents”. There are compile-time deps and link-time deps, and they are different. If I modify a .cc file I do not need to recompile anything that #includes the corresponding .h file. That is the whole point of .h files! But I do need to re-link the binary.

Yeah, exactly - it gets hella muddled.

Goes towards https://github.com/pantsbuild/pants/issues/12794

half-formed thought: It feels like this is a case where punning has generally worked before, but now doesn't. In Python, a file is both the exported symbols and the implementation, so referencing it as the target for all of that makes sense. For C/C++, these are not necessarily the same. There is also the fact that a file can be smaller than the smallest separable grain (pathological is many .h to many .c, but even a 1:1 .h to .c aren't always separable). So would it make sense to split the normally punned roles for a target into separate ones? like exported_symbols, source_code, translation_unit, ... . And then you could have different dependency rules for different purposes. So you could say that the

source_code

of "app/main.c" depends on the `exported_symbols`of "core/greeter.h"; but you can use different rules to infer that the

binary

of "app/main.c" depends on the

exported_symbols

of "core/greeter.h" so Pants knows it needs to find the

translation_unit

that includes those symbols and its associated

source_code