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.