[boost] CMake and the Boost Steering Committee

Subject: [boost] CMake and the Boost Steering Committee
From: Edward Diener (eldiener_at_[hidden])
Date: 2018-09-16 13:27:29

I think it is a huge waste of time for anyone to discuss or implement a 
CMake solution for Boost until the Boost Steering Committee actually 
gets involves and defines what "Boost using CMake" actually means and 
gives the specifics as to what this actually entails. Otherwise nearly 
everything said about Boost and CMake, although well-intentioned, is 
just a lot of hot air and we are going absolutely nowhere trying to make 
any progress in this so-called direction.

The Boost Steering Committee is largely at fault for saying that Boost 
would be using CMake, without defining what this actually means. Once 
again, as in our discussion about Boost dropping support for C++03, we 
are all wasting our time because the meaning of some language having 
been used is not clear and way too general to reach any meaningful 
conclusions. But in this case the only people who can really define what 
Boost using CMake actually means is the Boost Steering Committee, or 
someone representing the Boost Steering Committee on this mailing list,
who can clarify what Boost using CMake is actually about, since it was 
the Boost Steering Committee who made the decision in the first place.

If it is not the case that the Boost Steering Committee defines what 
Boost using CMake actually is supposed to mean but rather it is up to 
those on this mailing list to decide the issue, I would argue that Boost 
should focus on the simplest solution first, making Boost libraries, 
whether header-only or not, available for use in end-user CMake scripts 
in such a way that it will be easy to add this functionality for the 130 
or so individual Boost libraries with the least amount of effort or work 
involved for each library, without arguing unduly about more complicated 
or more purist solutions. In other words lets start with the easiest, 
most practical solution, because I assure you when the smoke has 
cleared, 99% of those people involved in the discussion will not want to 
do the practical work of actual adding necessary CMake scripts to any of 
the 130 or so libraries involved, and even the maintainers of those 
libraries will not want to spend much time implementing some complicated 
  CMake solution for their library.

But I still think that without a specific definition of what Boost using 
CMake actually entails from the steering committee we are just wasting 
time and breath and to no good purpose.