Generic --host_opt flag

[keith]

One thing we see come up a lot is needing to pass options that we pass to our build differently for the host configuration. In some cases bazel has a flag for this like --host_swiftcopt / --swiftcopt etc. In other cases, for whatever reason, bazel does not yet have a flag for the use case, such as #13001 or --host_features and how --features applies everywhere.

I think it would be useful for there to be a generic --host_opt flag with syntax such as --host_opt=--normal_opt=value that allowed you to pass through arbitrary bazel options to the host configuration.

This opens the door for much more API usage for the host configuration, but I think that could be preferred to the trade off of trying to add a host flag for ever applicable option.

[gregestren]

Agreed. @katre and I have thought about this problem for quite some time. It absolutely deserves a solution.

The broadest task is to design a user-facing API for modeling a host transition. That includes custom flags, as you describe. It also includes what a host transition means by default.

Right now host transitions are hard-baked into Bazel, with the logic "some flags get ported to the host config from the target config while others don't". That's the starting point. It actually isn't trivial to figure out the right answers: for some apps it's important that a flag propagates while for others it's important that it doesn't.

Maybe it could be as simple as --propagate_to_host=--a,--b,--c?

• Is it sufficient to embed that setting as its own flag or in a bazelrc?
• Should we support multiple host configurations? (the exec configuration work @katre leads is all about that)
• Should flags copy from the target configuration by default, be set to some static default, or have yet some other mechanism to decide?
• When new flags are added, how are they handled? The old --propagate_to_host=... setting is now outdated.
• If multiple target configurations, which one are flags copied from?

So in my view next step is writing up the design addresses these issues. @katre 's interested but to my knowledge neither nor I are committed to that now. As always we're happy to work with anyone interested in spearheading the process.

[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.

[fmeum]

@bazelbuild/triage Not stale