Bazel build does not default to -std=c++14 (or later)

[SagaciousB]

In trying to compile au, I found that a simple bazel test //...:all command resulted in errors out-of-the-box due to defaulting to the C++11 standard

Ex:

In file included from ./au/stdx/experimental/is_detected.hh:19: ./au/stdx/type_traits.hh:38:38: error: unknown template name 'conditional_t' struct conjunction<B1, Bn...> : std::conditional_t<bool(B1::value), conjunction<Bn...>, B1> {}; ^ ./au/stdx/type_traits.hh:46:38: error: unknown template name 'conditional_t' struct disjunction<B1, Bn...> : std::conditional_t<bool(B1::value), B1, disjunction<Bn...>> {}; ^ ./au/stdx/type_traits.hh:55:18: error: no template named 'remove_cv_t' in namespace 'std' typedef std::remove_cv_t<std::remove_reference_t<T>> type; ~~~~~^ ./au/stdx/type_traits.hh:55:35: error: no template named 'remove_reference_t' in namespace 'std'; did you mean 'remove_reference'? typedef std::remove_cv_t<std::remove_reference_t<T>> type; ~~~~~^~~~~~~~~~~~~~~~~~ remove_reference

I noticed that the build command included the flag -std=c++11 :

ERROR: ./au/au/BUILD.bazel:177:8: Compiling au/conversion_policy_test.cc failed: (Exit 1): wrapped_clang_pp failed: error executing command (from target //au:conversion_policy_test) external/local_config_cc/wrapped_clang_pp '-D_FORTIFY_SOURCE=1' -fstack-protector -fcolor-diagnostics -Wall -Wthread-safety -Wself-assign -fno-omit-frame-pointer -O0 -DDEBUG '-std=c++11' ... (remaining 51 arguments skipped)

Manually specifying via the --cxxopts flag fixes this issue: bazel test --cxxopt="--std=c++14" //...:all

Development Enviornment:

• Bazelisk
• Zsh
• MacOS 14

Note: the WORKSPACE file does include the following:

llvm_toolchain(
    name = "llvm_14_toolchain",
    compile_flags = {
        "": BASE_CLANG_COPTS + EXTRA_COPTS,
    },
    cxx_standard = {
        "": "c++14",
    },

but it doesn't appear to be used.

Potential Fixes:

• Investigate why the toolchain isn't using the cxx_standard above
• Add build:clang11 --cxxopt=-std=c++14 to .bazelrc
• Add --cxxopt=-std=c++14 to build/copts.bzl

[chiphogg]

Great to hear from you again, Brian!

This issue is surprising and concerning. It's definitely a goal of Au that any user should be able to simply clone the repo and build out of the box, with no setup required. That has been my and others' experience so far, but apparently it isn't universal. The issue might be mac related, but unfortunately, I don't have any way to test on a mac.

First: what happens if you run which bazel? (I get /home/chogg/au/tools/bin/bazel.)

Also, you say you're using bazelisk. Au includes bazelisk as well. Do you mean that you're using our bazelisk, or one you installed yourself? And what happens when you run bazel --version? (Should definitely be 6.0.0.)

Can you tell whether you're using the default llvm_14_toolchain and the cxx_standard option just isn't getting applied, or whether you're not even using the llvm_14_toolchain at all?

Also, does it use C++14 when you do bazel test --config=gcc10 //...:all, or bazel test --config=clang14 //...:all?

In terms of preferred fixes, I think the first would definitely be best. Right now, build:clang11 only contains options directly related to selecting the clang11 toolchain, and I'd really like to keep it that way.

[SagaciousB]

Thanks, Chip! Good to hear from you as well :-) I'll have to time-box this exploration, as it is sort of a side project

1. which bazel - /opt/homebrew/bin/bazel
2. I am using bazelisk installed via homebrew.
3. When executing bazel --version from the au/ directory, I see version 6.0.0 (note, executing in other directories without a .bazelversion, I get 6.4.0, indicating Bazelisk is working appropriately)
4. This might well be the issue... it doesn't look like the llvm_14_toolchain is being selected, despite me even trying to specify llvm or gcc10 with --config=clang14. The following debug command is helpful: bazel build --config=clang14 --toolchain_resolution_debug=.* //au:all

INFO: ToolchainResolution:     Type @bazel_tools//tools/cpp:toolchain_type: target platform @local_config_platform//:host: Rejected toolchain @gcc_toolchain_x86_64//:_cc_toolchain; mismatching config settings: gcc10_requested
...
INFO: ToolchainResolution:   Type @bazel_tools//tools/cpp:toolchain_type: target platform @local_config_platform//:host: execution @local_config_platform//:host: Selected toolchain @local_config_cc//:cc-compiler-darwin_arm64

So, despite me specifying the config, cc-compiler-darwin_arm64 gets selected...

This might also be telling:

Apple clang version 15.0.0 (clang-1500.0.40.1)

[chiphogg]

Ah --- that's a telling result!

I forgot to mention that the "just clone and run bazel" workflow has another step: setting up direnv to add our tools to your PATH inside the folder. So here are some more steps to try.

1. tools/bin/bazel test --toolchain_resolution_debug=.* //au/...:all.
2. Set up direnv according to these instructions, run which bazel, and then run bazel test --toolchain_resolution_debug=.* //au/...:all.

I'm not super optimistic that simply setting up the PATH correctly will work, but it may be worth a shot.

[SagaciousB]

Setting up direnv doesn't seem to have helped: 1. Still see INFO: ToolchainResolution: Type @bazel_tools//tools/cpp:toolchain_type: target platform @local_config_platform//:host: execution @local_config_platform//:host: Selected toolchain @local_config_cc//:cc-compiler-darwin_arm64

au % which bazel /Users/<$USER>/Code/au/tools/bin/bazel

[chiphogg]

Hmm... do you have evidence that direnv is otherwise working? Maybe something like which au-docs-serve, which should definitely not exist anywhere else. Or, more directly, echo $PATH both before and after you change into the directory. (You don't need to post the results here as that may contain private information, but it could be helpful in diagnosing.)

[SagaciousB]

I believe it is working. which au-docs-serve shows a valid path. When cd into the directory, I get % cd au direnv: loading ~/Code/POV/au/.envrc direnv: export ~PATH

And indeed, echo $PATH shows several entries added.

[chiphogg]

Sanity check: does the Au folder show up before /opt/homebrew/bin in PATH? Not that I would know how to fix the problem based on this, but it'd be nice to make sure that PATH works the way that I think it does. :sweat_smile:

So... where are we at here?

• When bazelisk is installed system-wide on MacOS via homebrew, it appears that we prefer to use that version, even when direnv is active and changing the PATH variable. (We will still want to double check to make sure that it's modifying PATH in the right way, putting Au at the start, but I expect that it is --- it'd be really weird if direnv were modifying PATH without doing this.)
• Bazel is not selecting the toolchain that we told it to select. It appears to be falling back on Apple clang. This seems like the real error; the incorrect bazel version is concerning, but may be a red herring.

I'm not really sure where to go from here. @philsc, if you get any spare cycles to look at this, do you have any ideas?

[philsc]

@SagaciousB , could you give the following a try?

bazel shutdown
export BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1
bazel test //...

That should prevent bazel from looking at your host system for a toolchain. If that works, we should be able to encode that in bazelisk.

I'm not entirely sure that the library we're using to set up clang will download a Mac variant, but I'm hopeful.

@chiphogg , is there any way to add a Mac machine to the CI setup? I'm guessing the answer is no.

[SagaciousB]

Sanity check: does the Au folder show up before /opt/homebrew/bin in PATH? Not that I would know how to fix the problem based on this, but it'd be nice to make sure that PATH works the way that I think it does. 😅

/opt/homebrew/bin is at the root level (not a subdirectory of the au/ folder). However, which bazel shows: /Users/<me>/Code/au/tools/bin/bazel and bazel --version matches the version specified in the .bazelversion (6.0.0) so I don't think this is causing any issues?

@SagaciousB , could you give the following a try?

bazel shutdown
export BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1
bazel test //...

This did not work:

ERROR: /private/var/tmp/_bazel_briansaghy/3047493c79fd1e640ae6a43cd0621331/external/bazel_tools/tools/cpp/BUILD:58:19: in cc_toolchain_alias rule @bazel_tools//tools/cpp:current_cc_toolchain: Unable to find a CC toolchain using toolchain resolution. Did you properly set --platforms? ERROR: /private/var/tmp/_bazel_briansaghy/3047493c79fd1e640ae6a43cd0621331/external/bazel_tools/tools/cpp/BUILD:58:19: Analysis of target '@bazel_tools//tools/cpp:current_cc_toolchain' failed INFO: Repository nholthaus_units instantiated at:

I tried setting --platforms=@platforms//os:macos but I get "Target @platforms//os:osx was referenced as a platform, but does not provide PlatformInfo"

[philsc]

Okay. So I think what's happening is that we don't ourselves define a toolchain for macOS. So Bazel falls back to auto-configuring your host toolchain. Not sure how Bazel decides to do this auto-configuration, honestly. Either way, it does not set up the compiler for C++14, it seems.

I'll think of some possibilities here.

[philsc]

@SagaciousB , what kind of Mac do you have? Is it an ARM-based one?

[SagaciousB]

Yes, it's an M2 MacBook Pro

[philsc]

Would you mind giving https://github.com/philsc/au/tree/c%2B%2B14-for-macos a try, @SagaciousB ?

I can't test it myself (no mac), but I hope it'll work.

EDIT: Or put another way, could you give https://github.com/philsc/au/commit/004fbb3542a954be0939d981aeff69272a751e8f a try?