Re: [boost] Proposal for moving Boost to CMake

a user-config.jam has to exist in one of several defined places, $HOME or $BOOST_BUILD_PATH. This is incompatible with wanting a scripted environment. Building everything in one go prohibits you from using a separate install prefix for each compiler, which is needed to build a separate root directory for each tool chain you might have. With CMake I literally just set the Compiler and compiler flags from the command line (-DCMAKE_CXX_COMPILER=whatever, etc). With boost, I'm not even sure how to do it. I think there is some undocumented feature to let you put a custom jam file in some random directory and then use some undocumented flag to somehow point b2 to use that directory to look for your jam file/build in. So I think it might somehow be possible to write a script to write a jam file for each compiler I want to use in a build directory and somehow do an out of tree build for boost in that directory pointing at that jam file. I don't know the magic steps to invoke for it. If it exists its certainly not documented. I test an internal code base with > 9 compiler configurations(from source) for the entire dependency chain. Just adding features to a jam manually is not an option; everything should be automateable. Anything not automateable gets broken. On Mon, Jun 19, 2017 at 12:28 PM, Daniel James via Boost wrote:

On 19 June 2017 at 01:53, Gary Furnish via Boost wrote:

...

For whatever its worth as a user who sometimes contributes patches to fix bugs, I don't use the system compiler and instead use scripts to test different builds of internal code (clang, clang with various sanitizers and options, different versions of gcc, etc). This is such a pain with boost build because of the difficulty of automating building multiple copies with custom compilers and flags with the same source tree. In cmake this is easy, you just change some command line flags, something trivial in scripts. In Boost, I think I got it working once using undocumented features after spending several hours looking around at docs, source code(!), and stack overflow. I now automatically just don't use boost libraries that aren't header only. I would rather rewrite code than fight with the build process. That is a bad state of affairs.

That's odd, that's one thing I've always found easier with boost build than any other build system. You add a target to your user-config.jam, such as:

using gcc : sanitize : g++ -fsanitize=address ;

Then run the build using something like 'b2 gcc-sanitize'. I think there's some way of specifying flags at the command line, but I find it's easier just to set up a number of configurations in the configuration file. So when developing unordered, if I want to run the insert tests, I might do something like this:

cd libs/unordered/test b2 -q insert_tests gcc gcc-std11 clang clang-std14

I have no idea how to do the same thing with cmake. As far as I'm aware with cmake you have to set up multiple build directories for each variant of each project. I've found it a real pain for building projects like libc++.

Just to make it clear, I'm far from an expert in boost build, and struggle with many other aspects. But I've never found cmake to be the land of milk and honey that I hear so much about. I'm also more than a bit fed up of cleaning up after other people's grand projects.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost