On 19 June 2017 at 01:53, Gary Furnish via Boost
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.