Boost logo

Boost :

Subject: Re: [boost] Switch to CMake -- Analysis
From: Groke, Paul (paul.groke_at_[hidden])
Date: 2017-07-21 15:14:50

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Thomas
> Heller via Boost
> Sent: Freitag, 21. Juli 2017 16:21
> To: boost_at_[hidden]
> Cc: Thomas Heller <thom.heller_at_[hidden]>
> Subject: [boost] Switch to CMake -- Analysis
> Let's look at users first. Yes, FindBoost.cmake has its problems, but it works in
> 90% of the cases (from my own experience). This can, and should certainly
> be improved. Providing the necessary XXX-config.cmake files is what fixes
> this. There has been movement in that direction, with code, which could be
> just improved upon. This will fix those cases. The other group of library
> consumers, expressed the urge to build boost directly as part of their build
> process. That hasn't been done yet, but I am pretty certain, there are no
> road blocks to actually write such a CMake Module, which invokes b2 instead
> of the compiler directly inside of the superproject. Together with the
> generated XXX-config.cmake files, this use case is covered. From my
> recollection of the various discussions, this approach was not contentious at
> all, it wouldn't even require interaction with all library maintainers, and all
> CMake users (existing or prospective) would immediately benefit.

I like this approach very much!

Just to check if I understand correctly: When you write "CMake Module, which invokes b2 instead of the compiler directly", do you mean a CMake Module which would also be able to generate the Jamfile, or would all Boost library authors/maintainers still have to manually write the Jamfile? Because if you meant the latter, do you think that the former would be possible?

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