Re: [boost] Proposal for moving Boost to CMake

On 6/18/17 7:30 AM, P F via Boost wrote:

...

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.

Hmmm - All of this might help the user (though I doubt it in my case, not that that matters). But I don't see how it concerns boost library development. Boost library development is concerned with building libraries and running tests. So it sounds like you're interested in making Boost a more satisfying experience for users of Boost Libraries. A worthy consideration which I believe many of use would support. I would support a working FindBoost for example as I use CMake to build ide. Sounds like you have something in mind like FindBoostSerialization, FindBoostHana, etc. Which might also be interesting - but it has nothing to do with library development. FindBoost can be made to work without boost developers doing anything differently. Why not make a separate project FindBoostxxx and include all anything you want there. The you don't have convince anyone to do anything, all you have to do is do it.