Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: P F (pfultz2_at_[hidden])
Date: 2017-06-17 04:27:27

> On Jun 16, 2017, at 6:44 PM, David Sankel via Boost <boost_at_[hidden]> wrote:
> 
> Howdy all,
> 
> This is a request for comments on a possible path for migrating Boost's
> build
> system to CMake. I am not speaking for the Boost Program Committee here,
> but I
> plan on bringing this up with them after getting feedback.
> 
> The motivation is simple. CMake is currently the dominant player in the
> area of
> open-source, cross-platform, C++ build-systems. I make this claim based on
> Google trends graphs and discussions with others at the conferences I attend
> (CppCon, C++Now, and ISO C++ meetings). If we make Boost buildable and
> usable
> out-of-the-box with CMake, we would significantly lower the barriers to
> entry
> for both Boost users and new Boost developers. Boost serves the greater C++
> community and making Boost more accessible would be of great utility.
> 
> * To ease the migration path, both Boost.Build (the current jam-based build
>  system) and CMake will be supported for a time.
> * Boost sources would provide a compatible, drop-in replacement for the
>  'FindBoost' module that is distributed with CMake.

Find modules are only for third-party libraries. Boost should only provide config packages, and then update cmake’s FindBoost to use boost’s cmake config packages.

> A CMake-based
> application
>  could point to it and, instead of using the system Boost libraries, Boost
>  targets would be built from source as part of the user build.
> * The built Boost **binaries** would also provide a compatible, drop-in
>  replacement for the 'FindBoost' module distributed with CMake. The
> behavior
>  is similar to the previous bullet, except the built binaries would be used
>  instead of the source code.
> * The style of the 'CMakeLists.txt' files would follow current best
> practice.
>  We'd resist the temptation to write macros which replace the core CMake
>  functions. There would be repetition in the files, to be sure, but I
> think we
>  should avoid attempting to innovate CMake. I've seen this fail on many
>  occasions and would like to keep our goal focused, at this point, on
>  migrating Boost to CMake. In the future we could revisit this.

Although, somewhat outdated, and incorrect in places, this repo has an example of building boost with proper cmake support:

https://github.com/boost-cmake/boost-cmake

However, I find this brittle and error-prone. Here’s an example of cmake for Boost.Fusion:

https://github.com/boost-cmake/boost-cmake/blob/master/listsfiles/libs/fusion/CMakeLists.txt

This doesn’t even handle fusion's dependencies, and it is a little incorrect.

I have been working on cmake modules to handle this, but I am in the process of refactoring it, here:

https://github.com/boost-cmake/bcm

One way the Boost.Fusion could be written is like this using the modules to generate the cmake package config:

bcm_setup_version(VERSION ${BOOST_VERSION})

find_package(boost_config)
find_package(boost_core)
find_package(boost_function_types)
find_package(boost_functional)
find_package(boost_mpl)
find_package(boost_preprocessor)
find_package(boost_static_assert)
find_package(boost_tuple)
find_package(boost_type_traits)
find_package(boost_typeof)
find_package(boost_utility)

add_library(boost_fusion INTERFACE)
add_library(boost::fusion ALIAS boost_fusion)
set_property(TARGET boost_fusion PROPERTY EXPORT_NAME fusion)

target_link_libraries(boost_fusion INTERFACE
    boost::config
    boost::core
    boost::function_types
    boost::functional
    boost::mpl
    boost::preprocessor
    boost::static_assert
    boost::tuple
    boost::type_traits
    boost::typeof
    boost::utility
)

bcm_install_targets(TARGETS boost_fusion INCLUDE include)
bcm_auto_export(TARGETS boost_fusion
    DEPENDS 
        PACKAGE boost_config
        PACKAGE boost_core
        PACKAGE boost_function_types
        PACKAGE boost_functional
        PACKAGE boost_mpl
        PACKAGE boost_preprocessor
        PACKAGE boost_static_assert
        PACKAGE boost_tuple
        PACKAGE boost_type_traits
        PACKAGE boost_typeof
        PACKAGE boost_utility
)

However, with dependencies this is not maintainable. But perhaps a `bcm_boost_depends` can handle this, like this:

bcm_setup_version(VERSION ${BOOST_VERSION})

add_library(boost_fusion INTERFACE)
add_library(boost::fusion ALIAS boost_fusion)
set_property(TARGET boost_fusion PROPERTY EXPORT_NAME fusion)

bcm_boost_depends(boost_fusion INTERFACE
    boost_config
    boost_core
    boost_function_types
    boost_functional
    boost_mpl
    boost_preprocessor
    boost_static_assert
    boost_tuple
    boost_type_traits
    boost_typeof
    boost_utility
)

bcm_install_targets(TARGETS boost_fusion INCLUDE include)
bcm_auto_export(TARGETS boost_fusion)

This is the direction I would like to take the modules, and I think this is much more maintainable. Code repetition is not good, and just boost has innovated C++, I see no reason it couldn’t help innovate cmake. Especially, since these modules do no stray from what standard cmake does.

> * There would be a list of CMake guidelines that we'd use.
> * Boost libraries should be buildable in isolation and use
>  'find_package(Boost...)' to discover their Boost dependencies.

I am just wondering how this would work. In general, this would require all the libraries to be built together. I don’t think libraries individually can provide components.

> * We would work with CMake towards eventually taking over maintenance of the
>  FindBoost module distributed with CMake.

Each library should provide its own package of the form `find_package(boost_*)`, and the we can update the cmake to search for those components first and then fallback on the guessing games.

> 
> I see this progressing with several milestones.
> 
> 1. Release of a CMake-buildable Boost and the CMake conventions. In this
> stage
>   each Boost library can be built in isolation or with the entire
> distribution

Sans circular dependencies. As libraries which have circular dependencies will always have to be built with the entire distribution, but hopefully having modularing building might push authors to fix the cycles.

>   and all the 'FindBoost' functionality mentioned above would be
> incorporated.

Wouldn’t we need to update `FindBoost` in cmake so this would work?

> 2. The unit tests for all Boost libraries are incorporated into CTest (the
>   CMake unit test orchestration tools).
> 3. The Boost infrastructure is modified to use CTest for unit testing.
> 4. Unit testing functionality is removed from Boost.Build.
> 5. Boost.Build is removed.
> 
> Although there are many other great ideas floating around (e.g.
> modularization
> of Boost, Boost-Classic, and Boost2), I'd like to keep this focused on
> CMakification of Boost because I think it is something that would have big
> impact and is small enough to be doable.
> 
> One question that is going to come up is "who is going to do all this
> work?".
> Once we decide on a direction, I don't foresee a problem making this happen.
> Between volunteers, the importance this project has for companies, and the
> Steering Committee reserves, we should have the resources necessary.
> 
> Another concern is that some authors may resist. Authors have a lot of
> leeway
> when it comes to how they maintain their libraries, what conventions they
> use,
> and backwards compatibility concerns. However, there are some things that
> authors need to conform to, such as our current Boost.Build build and
> testing
> infrastructure. I liken this to the development of a city: building
> developers
> can make their buildings however they want, but the streets, which control
> transit between buildings, are centrally regulated.
> 
> Thanks for your consideration.
> 
> -- David Sankel
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost