Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: David Sankel (camior_at_[hidden])
Date: 2017-06-17 04:51:47

On Sat, Jun 17, 2017 at 12:27 AM, P F <pfultz2_at_[hidden]> wrote:

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

I'd rather not tie cmakification of Boost to innovating CMake, at least not
at the outset. I think you have some good ideas in your bcm library, but
I'd like to see wider industry adoption before switching Boost to them. I
don't like the risk involved.

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

It doesn't require all the libraries to be built together and, yes,
libraries can provide components. See this talk:
https://www.youtube.com/watch?v=3eH4hMKl7XE

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

Hrm. Maybe.

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

Yeah, sans circular dependencies.

>
> >   and all the 'FindBoost' functionality mentioned above would be
> > incorporated.
>
> Wouldn’t we need to update `FindBoost` in cmake so this would work?
>

No, I don't think so.