Concept ACK.

Does this allow to simplify the msan ci with boost_cxxflags?

Actually, boost 1.71.0 (the version we use)'s ./build.sh does respect CXX env vars, see:

https://github.com/boostorg/build/blob/boost-1.71.0/src/engine/build.sh#L157

However, this was changed in boostorg/build@7497f61, which was first included in boost 1.76.0

The reason why you're seeing the current breakage in the first case is because our well-known var propagation in depends is limited to non-native packages, native packages do not yet get them: #18820 (comment).

However, I have not figured out why it works in the second case. My reading of boost's build.sh as of 1.71.0 seems to indicate that the --cxx and --cxxflags would be ignored: https://github.com/boostorg/build/blob/04efaac148671479b514db882b1c520dcaafe89e/src/engine/build.sh#L149-L155

So perhaps there's a CXX env var that's set somewhere in depends that we don't know about? Curious.

Guix builds

@dongcarl Thanks for having a look.

The reason why you're seeing the current breakage in the first case is because our well-known var propagation in depends is limited to non-native packages, native packages do not yet get them: #18820 (comment).

I'm not sure about this. If I just remove the setting of CXX and CXXFLAGS before calling ./build.sh, the package ends up being built with the CXX set on the command line. I was fooled into thinking that our current Boost supported the --cxx options, as when I started using them, things were compiled as expected. However I think the actual fix here, was removing the the setting of CXX and CXXFLAGS, which was undermining the CXX and CXXFLAGS being set by the user.

I've updated this change to just drop CXX="$($(package)_cxx)" CXXFLAGS="$($(package)_cxxflags)", and everything now works as expected. If CXX is not set, you end up with CXX=g++, which is the current behaviour. However if CXX is set, that compiler will be used, as opposed to the build failure which happens now.

We can look at using --cxx if/when we move to a newer Boost, i.e: #23340.

This is still broken:

$ make --no-print-directory -C depends native_b2 CC=clang CXX=clang++
Extracting native_b2...
/home/hebasto/GitHub/bitcoin/depends/sources/boost_1_71_0.tar.bz2: OK
Preprocessing native_b2...
Configuring native_b2...
Building native_b2...
###
###
### Using 'gcc' toolset.
###
###
clang++ --version
clang version 10.0.0-4ubuntu1 
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
###
###
clang++ -x c++ -std=c++11 -O2 -s -DNDEBUG builtins.cpp class.cpp command.cpp compile.cpp constants.cpp cwd.cpp debug.cpp debugger.cpp execcmd.cpp filesys.cpp frames.cpp function.cpp glob.cpp hash.cpp hcache.cpp hdrmacro.cpp headers.cpp jam.cpp jambase.cpp jamgram.cpp lists.cpp make.cpp make1.cpp md5.cpp mem.cpp modules.cpp native.cpp object.cpp option.cpp output.cpp parse.cpp pathsys.cpp regexp.cpp rules.cpp scan.cpp search.cpp strings.cpp subst.cpp sysinfo.cpp timestamp.cpp variable.cpp w32_getreg.cpp modules/order.cpp modules/path.cpp modules/property-set.cpp modules/regex.cpp modules/sequence.cpp modules/set.cpp execunix.cpp fileunix.cpp pathunix.cpp -o b2
cp b2 bjam
Staging native_b2...
Postprocessing native_b2...
Caching native_b2...

Note Using 'gcc' toolset.

Please consider an alternative #23571.

Please consider an alternative #23571.

Lets look at that for now.