Re: [boost] Proposal for moving Boost to CMake

Subject: Re: [boost] Proposal for moving Boost to CMake
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-06-17 00:27:14

On 6/16/2017 7:44 PM, David Sankel via Boost 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. 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.
> * 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.
> * We would work with CMake towards eventually taking over maintenance of the
>    FindBoost module distributed with CMake.

As has been pointed out by many people Boost Build does a number of 
things for building, testing, and creating documentation for a library 
which CMake does not do, whereas I have never seen any evidence of a 
single thing which CMake does which Boost Build cannot do. So in effect 
you are asking developers to give up a superior build product for one 
that is vastly more popular.

I have even asked about a CMake deficiency on the CMake mailing list, 
only to receive no answer at all. That is why I have the impression that 
CMake deficiencies are just ignored.

I do not want to debate. I am still waiting for anyone to show me CMake 
building all Boost libraries, including builds, tests, and 
documentation, with the same results that Boost Build currently does. 
Anyone ? Otherwise this endless suggestion of moving to CMake, because 
it is so popular with the general programming world, seems an absolute 
dead end to me.

BTW I am no great lover of bjam syntax or the undocumented internal 
complexities of the Boost Build system. But unless I can be shown a 
CMake system that can practically do what Boost Build does for 
maintaining libraries I believe your suggestion is a non-starter.

> 
> 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
>     and all the 'FindBoost' functionality mentioned above would be
> incorporated.
> 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