Redundant builds of dependencies due to shared objects in runfiles

[brians-neptune]

I've noticed that all (transitive) dependencies of rules_foreign_cc rules tend to get compiled twice, due to this code in cc_external_rule_impl adding the dynamic libraries to the runfiles. I find this surprising and generally undesirable, because it increases build times and increases the size of the runfiles tree for deployment. Also it's hard to make use of these shared libraries without violating the One Definition Rule if the actual rules_foreign_cc target links them statically (which is by far the most common I've observed).

The comment on the code in question says this:

# Include shared libraries of transitive dependencies in runfiles, facilitating the "runnable_binary" macro

Would a separate provider that runnable_binary finds using an aspect be an acceptable alternative? It could break backwards compatibility for anybody relying on these shared libraries being present in runfiles, but I suspect that isn't very common because these shared libraries are pretty hard to use.

[jsharpe]

@jheaff1 do you have any thoughts on this?

[jheaff1]

I’m unsure why dependencies are built twice. I’m not opposed to runnable_binary being reworked to avoid undesired behaviour

[brians-neptune]

I’m unsure why dependencies are built twice. [snip]

They get built twice because of PIC vs non-PIC. Bazel builds objects in PIC mode (with .pic.o suffixes) for linking into shared objects, but non-PIC mode for static linking.