Boost logo

Boost :

Subject: Re: [boost] Proposal for moving Boost to CMake
From: Gary Furnish (gfurnish_at_[hidden])
Date: 2017-06-19 21:44:26

This option *really* needs to be on
and that cmake file is the most amazing thing ever. Why can't we get
something like that made official at least?

On Mon, Jun 19, 2017 at 3:38 PM, paul <pfultz2_at_[hidden]> wrote:
> On Mon, 2017-06-19 at 14:57 -0600, Gary Furnish via Boost wrote:
>> 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).
> In general in cmake, I use a toolchain file for each toolchain I need to
> target. This way I don't need to pass a bunch flags when I invoke cmake. The
> user-config.jam is similiar.
>> 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
> You can pass the user-config.jam into b2:
> b2 --user-config=<path-to-user-config.jam-fil>
>> 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.
> Actually, you might be interested in this cmake file:
> You can drop this in the top-level boost directroy and rename it to
> 'CMakeLists.txt', and it will under-the-hood generate a user-config.jam file
> with the setting from the cmake toolchain, and then build boost using this
> user-config.jam file.
>> On Mon, Jun 19, 2017 at 12:28 PM, Daniel James via Boost
>> <boost_at_[hidden]> wrote:
>> >
>> > On 19 June 2017 at 01:53, Gary Furnish via Boost <boost_at_[hidden]>
>> > 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:
>> > oost
>> _______________________________________________
>> Unsubscribe & other changes:
>> st

Boost list run by bdawes at, gregod at, cpdaniel at, john at