Subject: Re: [boost] Proposal for moving Boost to CMake
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-06-18 15:43:36
On 6/18/17 7:30 AM, P F via Boost wrote:
>> 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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk