Replace hard-coded -g0 flags with a feature that can be used in the toolchain configuration.

[chandlerc]

Just stumbled across some lingering hard-coded compiler flags:

bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/CppOptions.java

Lines 1093 to 1094 in 76a8498

	coptListBuilder.add("-g0");
	cxxoptListBuilder.add("-g0");

Could these be removed?

Specifically, it'd be nice to have a feature similar to opt and fastbuild that can be used as a condition to enable flags specifically in the host build. Ideally, I would suggest host. This would cause the host build to enable both opt and host features. And in turn, the crosstool configuration could disable debug info in the host build even if it would be enabled as part of the opt build for the target.

I noticed this because as implemented, the code actually adds -g0 twice.

[hlopko]

AFAIK if there is a feature named host it will be enabled by Bazel for host configuration. It certainly did work in the past - @oquenchil is that still true?

[hlopko]

Yup it seems we use host and nonhost internally.

[hlopko]

So I think @chandlerc can implement what they need. It would still be great if Bazel didn't add -g0, it seems it's one of the very few remaining hardcoded flags.

[sgadrian]

I have custom rules that use the attribute parameter cfg="host" documented here:

https://docs.bazel.build/versions/master/skylark/rules.html#configurations

and these unexpected added -g0 flags is also present when I try to use the --host_compilation_mode=dbg. I was expecting to get debug information in my host build but was not.

[hlopko]

Oh I was very wrong! It turns out incompatible_dont_enable_host_nonhost_crosstool_features defaults to True in Bazel, but to False internally. So internally we have a way to detect host/exec configuration (and we use it), but in Bazel we cannot.

@katre is there a way to detect if we are in the host/exec configuration in Starlark? Right now it seems the only way is to check ctx.genfiles_dir.path.find("-exec-") but that seems suboptimal. Are there better/more supported ways?

If not, can we at least unflip incompatible_dont_enable_host_nonhost_crosstool_features in Bazel? It seems the flag was not as important as it seemed at the time given we still have it disabled internally, and toolchains/platforms work (although we don't use toolchains/platforms for C++, so maybe that is related? I honestly don't remember).

CC @oquenchil

[hlopko]

#13315 is in spirit a duplicate of this issue.

[katre]

We are (slowly) working to enable platforms and toolchains for C++ inside google and for Bazel users. Most of the difficulty comes from the interactions of the CC toolchain with Android and Apple code, and we're actively working to resolve that.

You're going to need @oquenchil to figure out whether or not incompatible_dont_enable_host_nonhost_crosstool_features is still needed, I don't have enough context in the state of the CC rules to know now.

[hlopko]

@katre what about a language independent way of querying if the current configuration is target or exec from Starlark? Is there a better way than inspecting the genfiles_dir.path?

[katre]

We don't currently have a way to do that. I think there's an open feature request but I don't think we've figured out the right way to expose that.

[hlopko]

I see, thank you!

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

[chandlerc]

How is one supposed to reach out to the triage team? Nothing I type into GitHub seems to do the trick. But this issue is still real, and still needs to be addressed. I don't understand how it is reasonable to just close it.

[fmeum]

@bazelbuild/triage Not stale