Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-18 14:30:15

> On Jun 18, 2017, at 12:08 AM, Robert Ramey via Boost <boost_at_[hidden]> 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`.