Re: [boost] Proposal for moving Boost to CMake

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.