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