Re: [boost] CMake Modularization

Subject: Re: [boost] CMake Modularization
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2016-10-02 20:18:52

> On Oct 2, 2016, at 5:16 PM, Peter Dimov <lists_at_[hidden]> wrote:
> 
> David Sankel wrote:
>> CMake's FindBoost.cmake interface is awkward to use sometimes, but it is how most CMake applications use Boost these days. If we could provide a drop-in replacement that builds from a source repository on an as-needed basis, it would get a ton of immediate use. Something worth considering.
> 
> After thinking about this a bit, I'm still not sure how are we to resolve the conflict between in-Boost use and standalone use of, f.ex. Hana.
> 
> The use case in which Boost libraries are brought into a project via git submodules requires a CMakeLists.txt file that is different from the one that standalone libraries currently use. As one example of the differences, standalone libraries find the system Boost installation and use that for their dependencies.

The libraries will need to some coordination and cannot use the `FindBoost` module provided by cmake(and it really doesn’t make sense if boost actually supports cmake). Instead a top-level cmake can bring the packages together, something like:

    set(BOOST_ALL TRUE)
    # Whatever cmake modulues boost provide
    include(cmake/BoostModules.cmake)
    # Include the libraries
    # Perhaps this could be globbed
    add_subdirectory(libs/fit)
    add_subdirectory(libs/hana)
    ...

Then in the library, the cmake would do something like this:

    # We are building standalone
    if(NOT BOOST_ALL)
        # BoostModules must be installed first, before building standalone
        find_package(BoostModulues)
    endif()

    # Find the dependent boost libraries
    find_boost_lib(BOOST_LIBS asio hana) 

So now, when building standalone `find_boost_lib` will call `find_package` to retrieve the exported targets. If its building in-tree, then `find_boost_lib` will just find the target name, and let cmake resolve the target during build.

This will let boost libraries to be built in-tree, which is useful for libraries with circular dependencies, and also can be built per-modulue. The only thing is that the boost cmake modules would need to be installed first.

Now if libraries want to be even more standalone, and not require the boost cmake modules, then the author could provide more conditionals in their cmake to provide that, but i think that is up to the author. I don’t really see it necessary.

Paul