Unnecessary recommendation for "linkstatic=1"

[fweikert]

Bazel sometimes suggests to use linkstatic=1, even though it is not necessary.

Original error report: https://groups.google.com/forum/#!topic/bazel-discuss/XcmwEnJSDNU

[gregestren]

To be clear, this occurs because of: https://github.com/google/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLibrary.java#L382-385

Conceptually, we can't remove all ambiguity for configurable attributes because in general one path may include object files while another doesn't (and we don't know when the warning is triggered which path will be chosen). But we can more finely tune it for cases like described in the original path, where all paths have object files (or all paths don't).

The only complication is the link above gets a https://github.com/google/bazel/blob/master/src/main/java/com/google/devtools/build/lib/packages/RawAttributeMapper.java to examine attribute values. It'll need an https://github.com/google/bazel/blob/master/src/main/java/com/google/devtools/build/lib/packages/AggregatingAttributeMapper.java instead to have the ability to iterate over all paths.

[bsilver8192]

Actually, after a bit of investigation I concluded that the issue is something different. When rule.isConfigurable("srcs", Type.LABEL_LIST) is true, the problem doesn't occur because the caller of appearsToHaveNoObjectFiles (https://github.com/google/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLibrary.java#L330) doesn't trigger the warning.

The problem is when there is something in srcs like a filegroup which gives different files depending on the configuration, which doesn't result in rule.isConfigurable("srcs", Type.LABEL_LIST) being true. I'm not sure if there is some simple way to detect that case and add that to the if on line 330, but I'm pretty sure that would solve my issue.

[gregestren]

Brian,

Can you show a repro case? (e.g. a specific bazel invocation combined with the example you outlined in the referenced groups link above)? It's not clear to me now this has anything to do with select. e.g. I think we can get the same behavior with something straightforward like filegroup(name = 'my_filegroup', srcs = [''empty.h])

I think the more immediate distinction between having a filegroup in the sources vs. a direct source file, e.g. empty.h, is that the latter won't trigger on this check:

https://github.com/google/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLibrary.java#L401

[gregestren]

There's actually a comment to this effect here: https://github.com/google/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLibrary.java#L366

[bsilver8192]

I can't reproduce this any more. I don't remember exactly which version I was using, but I am only seeing the warning in configurations which don't have any .cc files in srcs with a recent one. Before, I (at least though I) was seeing the warning in all configurations, even ones in which there was a .cc file in srcs. I think this bug should be closed now. Thanks for looking into it.

Some extra details:
A simple case like you mentioned (filegroup(name = 'my_filegroup', srcs = [''empty.h])) does trigger the warning in the current version and probably would in the original one too, but it's correct.

That comment at https://github.com/google/bazel/blob/master/src/main/java/com/google/devtools/build/lib/rules/cpp/CcLibrary.java#L366 disagrees with what I have observed about the actual behavior; I haven't seen any way in which the name of a filegroup affects whether the warning appears or not.

The actual rules where I was hitting the warning seem to have been some combination of this issue and an intermediate cc_library I missed before which actually had only headers in one configuration.

[kayasoze]

There is another case in which this warning is spurious: a cc_library() which contains a .a or .so (or both) in srcs[]. This configuration is useful when wrapping an autoconf or cmake generated library to pick up include paths.