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

Subject: Re: [boost] Request for a "Policy Review" regarding 'CMakeLists.txt'
From: Bob Summerwill (bob_at_[hidden])
Date: 2016-05-16 13:38:04

As a complete neutral here, I think that Michal is very much on-point.

I've been a C++ programmer for 20+ years, and have used boost on-and-off
for much of that time.

For much of my professional career I have been working with build systems
and configuration management, and I know much more about C++ build systems
than a person who wishes to remain sane should know :-)

I've used make, autotools, MSBuild, CMake, jam, scons, Premake, and more.

CMake has "won".    It isn't perfect, but it's the utterly dominant defacto
standard.   Unless there is an amazingly compelling reason not to migrate,
putting together a CMake migration plan makes good sense.

And the same kind of thinking should be applied to issue tracking, version
control, automation, etc, IMHO.

It is only through my involvement with Ethereum that I am now more closely
looking at Boost as a DEVELOPER rather than as a USER, and it looks awfully
old-fashioned and stick-in-mud to me, I have to say, sadly.

Anyway - enough from me ... best wishes to you all.    You have a gem with
your codebase.   Please don't let it wither on the vine ...

On Mon, May 16, 2016 at 9:32 AM, Michał Dominiak <griwes_at_[hidden]> wrote:

> 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
> >
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

-- 
bob_at_[hidden]