Re: [boost] Proposal for moving Boost to CMake

> On Jun 18, 2017, at 10:43 AM, Robert Ramey via Boost  wrote:
> 
> 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).  

There is no reason to doubt that user would find this helpful, otherwise users wouldn’t ask for such features. And it may seem like it doesn’t matter at this point for `safe_numerics`, except if you or one the libraries you depend on decide to use a compiled component this will effect both you and your users.

> But I don't see how it concerns boost library development.  Boost library development is concerned with building libraries and running tests.

And also distribution. Nobody is going to use your library without distribution.

> 
> 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.  

No, something like boost_serialization-config.cmake or boost_hana-config.cmake. Find modules are for third-party libraries that don’t support cmake consumers.

> Which might also be interesting - but it has nothing to do with library development.  

It does, because each library knows its usage requirements and when they will change, thus each library should provide that to the users.

> 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.

This does work currently because cmake developers have reversed-engineered the usage requirements, so I can write something like this in cmake:

find_package(Boost)
target_link_libraries(myLib boost::asio)

However, when I upgrade boost, I need to upgrade cmake as well. There really shouldn’t be a coupling between cmake and boost, like that. Instead each library can provide the cmake configuration, and we can update cmake’s FindBoost module to look for these configuration files, or the user can just call them directly with `find_package(boost_asio)`.