Re: [boost] Switch to CMake -- Analysis

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.

+1
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?