Rewrite cc_configure

[hlopko]

Current cc_configure is greatly suboptimal:

• It doesn't follow standard gnu env variables for customization (Autoconfigured unix crosstool should respect standard environment variables #5186).
• It doesn't support the same env variables between linux/mac/windows
• It's not even using the same logic between linux/mac/windows.
• It's not unit/integration tested (https://docs.google.com/document/d/1oilIxMGYuN1HgWouvGDYqjrZLtcRfyoWv3eIlXIgasY/edit?ts=5c06470d#)
• It's using legacy fields/crosstool in proto, we will need it to be in Starlark
• It prefers gcc over clang
• It doesn't support thinlto/modules
• It's not always used (e.g. freebsd has a separate static toolchain, //tools/cpp:CROSSTOOL is another static one we use).
• Ideally we'd have CUDA support (Native CUDA support #6578).

[PiotrSikora]

It should also include the ability to easily switch between GNU libstdc++ and LLVM libc++.

Currently, this requires either:

• changes to unix_cc_configure.bzl,
• custom cc_wrapper replacing -lstdc++ with -lc++ for each invocation.

I think this problem falls into overall theme of this issue, but please let me know if I should open a separate issue to track this. Thanks!

[htuch]

Some earlier context on libc++ and Linux at #4524

[hlopko]

@PiotrSikora and @htuch - is passing BAZEL_LINKOPTS="--stdlib=libc++:-lc++" not enough to use libc++? I think it works, at least on linux.

[PiotrSikora]

@hlopko you need to pass -stdlib=libc++ to the compiler (hence BAZEL_CXXOPTS), otherwise you'll include C++ headers from libstdc++ and not libc++.

[hlopko]

Yup. you're right. All of this is doable with Bazel today. Is this enough for you, or you'd want an ability to switch it more easily than that?

[PiotrSikora]

Yup. you're right. All of this is doable with Bazel today.

I wanted to verify that BAZEL_CXXOPTS can be set in .bazelrc using --action_env, so I updated Bazel to 0.23rc1, and even though local_config_cc/cc_toolchain_config.bzl is generated correctly and includes proper cxx_builtin_include_directories, cxx_flags and link_flags, it appears that libc++ builds are completely broken in 0.23rc1.

Perhaps cxx_builtin_include_directories are not included in the sandbox?

fatal error: 'string' file not found
#include <string>

Tests to catch any regressions there would be great.

Is this enough for you, or you'd want an ability to switch it more easily than that?

Personally, I'm fine with adding a few lines to .bazelrc to enable --config=libc++ myself, though it would be great if it just worked out of the box :)

@htuch @jmillikin-stripe Do you guys have any opinion on that? The two of you are a bit more pedantic, when it comes to the build system, than I am.

[hlopko]

cxx_builtin_include_directories are only for .d file validation, if you need to add those directories and their contents to the sandbox, you have to update filegroups in cc_toolchain target. Does that help?

[PiotrSikora]

@hlopko the same build works fine with Bazel 0.22, so I doubt it's something that fundamental.

Any chance you could take a look at it? The build instructions are pretty easy.

[hlopko]

Hi Piotr,

could you pls check if its #7397? I'd build bazel at 71bc38f and then one commit before and see if it's the culprit. If so, pls comment on the issue. Thanks so much!

[PiotrSikora]

@hlopko sorry, it appears that there was a change that broke local builds with libc++ in our build system committed at the time when I was testing 0.23rc1, and after reverting it 0.23rc1 seems to work fine. Sorry for the noise!

[keith]

Here's another use case that would be nice to cover so that users can override some pieces of the toolchain, without having to create their own crosstool #7883

[hlopko]

From email threads:

• MSVC: SDK version selection - have an ability specify which version of the sdk to use.
• ARM64 on Windows - cover this platform as well.

[ccontavalli-j]

Also consider environments where multiple compilers may be available and necessary to build different targets. For example, having a dependency on a library that can only be built with gcc, and a different library that can only be built with clang.

A way to do this would be to extend cc_configure and/or cc_autoconf.* to take parameters, so one can specify a path for the compiler to use, for example, and the name of the toolchain to create.

Those parameters can be filled in by default from environment variables, or detection code, but you can leave the option to call cc_configure() with the correct parameters to use of bazel to simplify the detection and creation of multiple toolchains.

See also: #7020

[sgowroji]

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.