Subject: Re: [boost] Cmake
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2017-06-24 15:55:41
On Sat, Jun 24, 2017 at 3:59 AM, Peter Dimov via Boost <
> There is considerable interest in Boost supporting CMake, but it seems
> that everyone has different ideas as to what this support will entail.
> After deliberation and discussions, I have identified the following
> (separate) scenarios:
> 1. The user installs a Boost release as usual with `b2 install`, which
> makes the installation visible to CMake and usable via
> 2. The user brings several Boost libraries as git submodules into his
> CMake-based project and uses add_subdirectory in his CMakeLists.txt to link
> to them.
> 3. The user uses CMake to install an individual Boost library, which is
> then available for find_package.
> 4. The user uses CTest to run the tests of an individual Boost library.
> 5. CMake is supported as a way to build and install the entire Boost, in
> place of b2.
> 6. CTest is supported as a way to run the tests for the entire Boost, in
> place of b2.
> At the moment, I think that we should concentrate on (1) and (2) as
> providing most bang for the buck. 5-6 in particular require that all
> Jamfiles are ported at once, which is a serious undertaking for a
> questionable benefit as what we have already works.
> I've done a proof of concept for (2), which can be seen here:
> This repository uses git submodules in ext/ to bring in Boost.System (our
> guinea pig) and its dependencies, then uses them via add_subdirectory in
> The required CMake infrastructure is on branch feature/cmake in those six
> libraries (assert, config, core, predef, system, winapi.) It consists of
> CMakeLists.txt in the root:
> and supporting .cmake files in cmake/ :
> The goal here is for Boost library developers to be able to remain
> ignorant of CMake if they so choose; so of those files, only sources.cmake
> requires their input (it's empty for header-only, so those require nothing
> at all.)
> BoostVersion.cmake and default.cmake are common for all libraries and are
> copied from the superproject. dependencies.cmake is automatically generated
> with boostdep. There is a Jamfile in cmake/ that updates these three files:
> and the intent is for this to be done automatically in a superproject
> script that invokes "b2 cmake" for the superproject:
> which in turn invokes "b2 cmake" in each library having "cmake/Jamfile".
Interesting work. But...
Copying BoostVersion.cmake and default.cmake, instead of referring to them,
> allows libraries to be used without a superproject, to support scenarios
> (2) and (3) above. (Scenario (3) is also supported by default.cmake.)
Since I'm OCD about "extra" stuff I ask.. Would it not be better to have
the user run a command *after* cloning the submodules and dependencies that
generates all this for them?
Generating these -config.cmake files would ideally be done as part of the
> `b2 install` procedure and require no changes to the individual libraries.
> The changes to the `b2 install` procedure significantly exceed my bjam-fu
> however, so if we decide to proceed with this - and I don't see how we
> could claim CMake support in a meaningful way without it - the interested
> parties would need to figure out a way to make that happen. At this point,
> I know what needs to be done, but not how to bring it about.
Would achieving this be made easier by having b2 generate meta-data that
some other program can use to generate the desired files? For example
generating an XML (or JSON) file describing all the installed targets with
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk