Subject: Re: [boost] Cmake
From: Gary Furnish (gfurnish_at_[hidden])
Date: 2017-06-24 16:08:59
On Sat, Jun 24, 2017 at 9:57 AM, Stefan Seefeld via Boost
> On 24.06.2017 04:59, Peter Dimov via Boost wrote:
>> 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:
> I'm a bit confused by the listing, as you use the term "user" in quite
> different ways.
>> 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.
> All but 1) are addressed at boost developers, i.e. people who want to
> build (, test, etc.) boost itself. Only 1) is concerned about users who
> want to use boost as external dependency to their own project.
>> At the moment, I think that we should concentrate on (1) and (2) as
>> providing most bang for the buck.
> To be honest, I don't quite understand 2). Why do you want to support
> building boost (or parts of it) as an integral part of something else ?
> Modularity and encapsulation doesn't seem to have any value to you, or
> does it ?
As good as modularity and encapsulation sound they make it very hard
to test code. Even different distributions sometimes patch packages
of the same version the same without anyway to detect this. If you
don't build boost as part of your program you can't certify its bug
free with tests. And forget certification of bug free between
different versions of boost! It is simply not an option to rely on
external libraries when stuff must test clean. What mechanism you use
to do this various but modularity and encapsulation are a dream.
>> 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 agree. (In particular, I very much doubt that you'll get the required
> buy-in from all maintainers. I for once am strongly opposed to adding
> another bit of infrastructure to my project, which I won't be able to
> maintain myself.)
> ...ich hab' noch einen Koffer in Berlin...
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk