Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: paul (pfultz2_at_[hidden])
Date: 2017-06-19 21:38:02

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