Re: [boost] Proposal for moving Boost to CMake

On Jun 18, 2017, at 12:08 AM, Robert Ramey via Boost wrote:

On 6/17/17 8:55 PM, P F via Boost wrote:

...

...

I also looked at Hana usage of CMake. I have to say it's quite off-putting for a library author to be required to learn a huge amount of CMake lore and prepare 500 lines of script across several files just to submit a header only library which. I agree which is why I am writing cmake modules to help make this more straightforward.

* only needs to run tests * users need only point to the header library. A header-only library needs to do more than this. It needs to install the headers as well as the usage requirements(through exporting the target)

Hmmm - I never felt the need for this. I just copy a library to my system and add the directory to the list of directories to be searched. What could possible be easier than that.

Much easier to say `cmake --build . --target install` or `install lib` from a package manager then manually figuring out what files need to be copied. Furthermore, this prevents installing the usage requirements, which it is much easier to say `g++ $(pkg-config boost_asio --cflags --libs)` or `target_link_libraries(myLib boost::asio)` then trying to figure out all the compiler and linker flags needed to use asio. A header-only should still provide its usage requirements, because: * It may require linking in other libraries. Although a library is header-only it may depend on non-header-only libraries. This is the case for Boost.Asio, which needs to link in other libraries. * A library may change usage requirements in the future. A library could change from header-only to being built, or it could bring in a new dependency that requires linking in a new library. This would affect all downstream libraries, but if the build scripts are using the usage requirements this will require zero changes to the build scripts.

...

...

Actually, this example makes bjam look much easier than CMake which I believe conflicts with the original premise which motivated the proposal. I don’t think its a fair comparison to bjam as its not doing the same thing. The bjam files in boost for header-only libraries do not individually install headers or usage requirements.

Hmmm - Now I don't know what the proposal is. I thought it was to replace bjam. I don't know what else it needs to do. I see CMake as an alternative way of building and testing libraries. I don't see this impacting users in any way. I thought I knew what is being proposed but now I don't think I do. Perhaps this proposal should be something more specific than "Moving Boost to CMake”.

I believe the proposal was to move to cmake using cmake’s best practices for building, testing, and supporting `find_package`.