Re: [boost] Request for a "Policy Review" regarding 'CMakeLists.txt'

Subject: Re: [boost] Request for a "Policy Review" regarding 'CMakeLists.txt'
From: Michał Dominiak (griwes_at_[hidden])
Date: 2016-05-16 12:32:29

Hi,

The thing is, despite whether you believe bjam is better than CMake or not
(please tell me how I can easily build Boost.MPI with Bjam without an
additional config file that allows me to *just* do that?), there's another
very important aspect of the problem, and it's whether Boost will survive
in the current C++ world, where everyone uses CMake. People writing code to
build independent parts of Boost for static linking in their libraries or
tools that are supposed to be portable, regardless of the target or build
OS, are already building it with CMake... probably because everything else
in the world is built with CMake (or with autofo-- autotools, but that's
easy enough to wrap with ExternalProject - for the record, I'm not saying
that it's good). An example from the top of my head: YCM.

This isn't really a discussion that needs to go deeply technical, but if
you want to do that, by all means, please do point out what bjam does
better than CMake - as in, please make a list of stuff that is so great in
bjam, so that we can actually discuss this technically (just mentioning
usage-requirements doesn't do this for me, because if I understand the docs
correctly, it's trivial to do this in CMake). For the record: I work with
CMake on a daily basis at work, and I feel deep hatred for some of
its idiosyncrasies, but I like it far better than working with bjam (and
trust me, I've build my fair share of different Boost configurations over
the past few years).

Now; we could make a poll to see whether the distribution of people for
CMake among all Boost members is the same as it was at the panel at C++Now
(where the vast majority of people raised their hands after the SC asked
who wants Boost to be converted to CMake - or thinks it *needs* to be
converted), but I don't know if going there is productive; what Dave and
David said about the future and the deep need to actually make a move there
and not get eaten by everybody who does that is probably the primary
argument for actually doing the switch here.

I realize I am kinda derailing this thread, and there's a chance this
should be made into a separate one; that might actually be a good idea.
Just let me say one more thing.

I spoke with a few (as in: not so many of them; I wish I thought about this
earlier than Saturday) at C++Now, including Dave, and asked them whether
they think that the glue between different Boost libraries, that is: the
build system used for the entire thing - should be considered a part of
each individual library, or as something that is outside of the scope for
each individual library, and rather a part of Boost itself, which would 1)
make the authors of each library not actually own their build systems, just
the code (which I believe is a good thing) and 2) make the Steering
Committee the de facto owner of the build system *across Boost*, which, in
turn, would allow them to make a decision saying "we are going to switch to
CMake over the next X years/releases/whatever, and here's how we are doing
it".

I believe that (2) should be done; if we just *encourage* library authors
to also support CMake in their libraries, it will result with a lot of
build systems that are separate entities, when I believe that they should
be standardized across Boost - and this is the part when I don't believe
that without the SC's definitive and authoritative voice saying "this is
how it's done", it won't be done in a way that could potentially be made
official, because of the differences different people have about build
systems.

In the end, this is about moving forward, instead of staying in the same
place forever, because as in many different industries, in this one not
moving actually means moving backwards, and moving backwards is the kind of
a thing that can murder Boost.

I expect people to raise opinions of "this is too radical" and "why should
we listen to somebody posting on these mailing lists for the first time
with a message like this one?"; that is fine. But the primary goal I have
here is to remind you again (or tell you, if you weren't there) what Dave
said on Saturday: the Steering Committee's role is to protect Boost. I
believe that not moving forwards with an actual, active (as opposed to
passive "yeah, you can do this; whatever") switch to CMake (*even despite
any actual technical argument proving Bjam's superiority!*) is actively
harmful in the era where almost all relevant (this includes proprietary!),
big C++ projects that are not GNU are using CMake to build themselves.

A final note, again kind of repeating what Dave said (because I think it's
extremely important and we tend to forget it these days): Boost is supposed
to serve *the entire C++ community; it isn't Boost's goal to serve Boost's
community*.

Thanks in advance for no open hostility in replies to this, hopefully we
can make some progress thanks to Saturday's discussion that basically
sparked this email.

On Mon, May 16, 2016 at 5:48 PM Mikhail Strelnikov <
mikhail.strelnikov_at_[hidden]> wrote:

> >
> >
> >     * Several libraries, such as Boost.Hana and Boost.Spirit, have two
> > distribution mechanisms: one as distributed with Boost and the other as
> an
> > independent package.
>
>
> What if header-only library A is using Hana from Boost 1.61 and header-only
> library B is using independent Hana released in 2017? Will this violate ODR
> (if compile at all) if both A and B are used in the same application?
>
>
> > The requirement that these libraries not include a
> > 'CMakeLists.txt' as part of their Boost distribution creates a
> maintenance
> > burden for authors or otherwise hurts usability of the independent
> > distribution.
> >
> >
> Hana does already include CMakeLists.txt in 1.61, why is that?
>
> Why header-only library such as Hana needs a build script that is 5 pages
> long (plus walls of text in cmake directory)? Bjam does support header-only
> libraries and does not require much from library author.
>
> If you have 1.61 extracted, navigate to boost/libs/hana/CMakeLists.txt line
> 105 and please tell me why library included in Boost 1.61 is trying to
> search for Boost 1.59? Do you want every Boost library to search their own
> version of Boost?
>
> It requires CMake 3.0 released in 2014 and searches for Boost 1.59 released
> in 2015 - this is not going to work. Best FindBoost.cmake has to offer
> is 1.56.
>
> What BOOST_HANA_HAS_WEXTRA does?
>
> What is boost/libs/hana/LICENSE.md doing? Is this legal?
>
>     * Several companies have revealed that they are building Boost with
> > their own custom CMake scripts. The suggested policy change would enable
> > authors to relieve the infrastructure cost of their CMake users and unify
> > how their library is built.
> >
> >
> I have opposite experience by replacing dozens of CMake scripts with one
> tiny Jamfile.
>
>
> >     * CMake is, by far, the most popular build system for C++. Allowing
> > authors to support CMake users in addition to BJam will help the Boost
> > ecosystem to grow and thrive by lowering the barriers to access.
> >
> >
> IMHO, CMakeLists.txt looks ugly as everything in camel starting with C.
> There are lots of Boost libraries having only "index.html" in their
> top-level directory, look, there is a pattern here and I'm not sure this
> should be uglified.
>
> I don't care too much about popularity, but Bjam/BB does support C++ much
> better than CMake. It has, for example, "usage-requirements".
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>