Re: [boost] Proposal for moving Boost to CMake

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
"http://www.boost.org/build/doc/html/bbv2/overview/configuration.html"
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:
>
> https://github.com/pfultz2/cget/blob/master/cget/cmake/boost.cmake
>
> 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: http://lists.boost.org/mailman/listinfo.cgi/b
>> > oost
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boo
>> st