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.