Project-wide platform-dependent compiler options

[david-german-tri]

Description of the problem / feature request / question:

If asking a question or requesting a feature, also tell us about the underlying problem you're trying to solve.

At RobotLocomotion/drake, we're migrating from CMake to Bazel (yay!). We target gcc on Ubuntu, clang on Ubuntu, and clang on OS X.

There are some compiler flags that we need set differently from the Bazel defaults, and differently for gcc than for clang. For instance, the GCC spelling of a particular warning is return-local-addr, while the Clang spelling is return-stack-address. Bazel doesn't promote that warning to an error by default in cc_configure, but we want to do so in Drake. We want it to take effect automatically on all build targets present and future, both on developer workstations (regardless of platform) and in CI.

We considered a few approaches, all of which seem to work, and none of which are wholly satisfying. Do you have recommendations?

1. Add the platform specific flags to tools/bazel.rc using --cxxopts, controlled by --config switches named gcc and clang. Possibly ship a wrapper script around Bazel that auto-selects config switches, or else just document it carefully and do the right thing in CI.

2. Write a Skylark wrapper macro around cc_library that automatically populates copts with platform-appropriate flags, based on a select statement over a config_setting that examines cpu and compiler. Replace all uses of cc_library in our BUILD files with this macro, and add linter logic to ban cc_library going forward.

3. Write our own hard-coded CROSSTOOL toolchain stanzas for our supported platforms, by hand-editing the output of cc_configure. Check the CROSSTOOL file into our own repo along with the supporting BUILD files and scripts from tools/cpp.

4. Write a repository_rule that procedurally edits the output of cc_configure as in (3), using a lot of grep and sed. This is the approach we've tentatively chosen: Add compiler-specific warnings in Bazel. RobotLocomotion/drake#4717. It's by far the ugliest under the hood, but seems to put the least burden on our developers and users.

Environment info

• Operating System: Ubuntu Trusty/Xenial and OS X

• Bazel version (output of bazel info release):

  • OS X: release 0.4.3-homebrew
  • Ubuntu:release 0.4.2

Have you found anything relevant by searching the web? (e.g. GitHub issues, email threads in the bazel-discuss@googlegroups.com archive)

This thread recommends using config_setting and select in the BUILD file to inject platform-specific options via the copts argument to cc_library. Like alternative (2) above, but without the macro.

Many thanks!

[hlopko]

Hi David, sorry for radio silence. Is this issue still relevant?

[jwnimmer-tri]

I can reply on behalf of David.

For the warning flags, we ended up doing option (2). See our tools/drake.bzl. This is probably the right choice for Werror-foo flags, where we want to ratchet them up for our first-party code but leave them lax (and muted) for third-party code.

For other flags, we ended up doing option (3). See our checked-in CROSTOOL file, with file-top comments explaining how we generate it.

I think these choices have worked well in practice, because our matrix of supported platforms and compilers is known a-priori and relatively small. YMMV.

I would still be happy to hear any advice from the Bazel team about different suggestions, but if there is nothing more to add, we can consider this issue closed.

[hlopko]

Hi Jeremy,
what you did makes sense and I see nothing wrong about it. I can offer one alternative, and that is using crosstool features. They have one benefit, and that is that all flags are specified on one place, in the crosstool. Here are some examples:
https://github.com/bazelbuild/bazel/blob/375f95b16e1a8b164d2caaa4d65a4c9b4e310bd3/src/main/java/com/google/devtools/build/lib/rules/cpp/CppActionConfigs.java

bazel/tools/osx/crosstool/CROSSTOOL.tpl

Line 220 in 375f95b

feature {

You can enable the feature by default using enabled: true, or you can enable it only for some targets, e.g.:

cc_library(
    name = "foo",
    features = ["additional_flags"],
    ...
)

You can also specify them on package rule, and also as bazel option (--features=a,b,c).

Feel free to continue discussion here, I'm closing the issue just so we know there are no action items for bazel (and will reopen if some show up).

[jwnimmer-tri]

Excellent, thank you. Next time we are updating our CROSSTOOL we will take a look. I think considering this issue closed is appropriate. Thanks again!