Re: [boost] Switch to CMake -- Analysis

Am 21.07.2017 5:15 nachm. schrieb "Groke, Paul via Boost" < boost@lists.boost.org>:

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas Heller via Boost Sent: Freitag, 21. Juli 2017 16:21 To: boost@lists.boost.org Cc: Thomas Heller 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? I mean the latter. Using the existing jamfiles. I don't see value in replacing the already existing ones with auto generated so I haven't thought about it. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost