bazelbuild
cxxopts and conlyopts parameters to cc_library
Description of the feature request:
C and C++ compiler options are very related, but not always identical, ranging from variations in language specifiers and even warnings flags. For example GCC uses slightly different names for the same warning between C and C++: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmissing-prototypes https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wmissing-declarations
Bazel does have --cxxopt and --conlyopt flags, but there is no way to do it from a build file. (A library project cannot control the flags used by upstreams.) It is possible to workaround this by splitting the target in two, but this is messy, particularly in a library project that already needs to support multiple build systems.
Other build tools already have this capability. https://discourse.cmake.org/t/language-specific-add-compile-options/2643 https://www.gnu.org/software/automake/manual/html_node/Standard-Configuration-Variables.html https://gn.googlesource.com/gn/+/main/docs/reference.md#var_cflags
Which category does this issue belong to?
C++ Rules
What underlying problem are you trying to solve with this feature?
See above
Which operating system are you running Bazel on?
All
What is the output of bazel info release?
No response
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
I'm leaning to P3, but I'd need more inputs of what can potentially be affected.
Do you mean that you need examples of projects that need it and use cases? Please see the bug report. BoringSSL has been having to work around this Bazel limitation for some time, as the build system simply does not meet our needs right now.
Indeed our testing fidelity is much worse than it could be because of Bazel here; as a library with some C++ internals but a C API, we would ideally have tests where our APIs' immediate callers are C. But this issue means that mixed C/C++ test binaries are so difficult to arrange that we largely don't bother. It also complicates incremental migration of the C portions of the library to C++.
https://github.com/bazelbuild/bazel/issues/23460 is another consequence of this bug. What can be done to prioritize this issue? This issue means that BoringSSL, a key dependency of many Google Cloud projects, is unable to effectively use Bazel.
Bumping this as we're needing to now work around a workaround of a workaround of this bug.
I took a pass at this for cc_library and cc_binary, ptal: https://github.com/bazelbuild/bazel/pull/23792
