Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Chris Glover (c.d.glover_at_[hidden])
Date: 2017-07-18 20:24:55
On Tue, 18 Jul 2017 at 15:00 Louis Dionne via Boost <boost_at_[hidden]>
> (1) Users have a hard time integrating Boost into their build system, which
> is CMake
> more often than not (but not always, and we're trying to please the
> majority here)
> (2) Prospective Boost developpers are sometimes driven away from submitting
> they would have to use Boost's build system, which they don't know.
> Furthermore, there was an implicit understanding that if the community as a
> whole objected to any change or could not come to any consensus, nothing
> would be forced onto it. However, the _intent_ is clear, and it is that
> if we do have a good solution for solving problems (1) and (2), we should
> do it (as opposed to rejecting it, like what has happened in the past).
> I would love to see the Boost community come together and figure out how
> we can solve problems (1) and (2) in the best possible way.
It has been discussed multiple times that supporting (1) does not require
switching to CMake.
(2) probably does, but from my point of view, that would actually make
boost less usable in my work environment.
I use CMake for all of my personal and open source projects and it's great
for that, but no company I have worked for has used CMake internally for
anything. I'm sure that there are companies that do, but in my experience,
every big C++ shop maintains their own custom build system so switching to
CMake will add a new dependency that didn't previously exist. It's probably
not a deal breaker, but it is a regression because every time I upgrade
boost, I might need to upgrade CMake, and because we don't rely on system
installed packages for anything I would need to upgrade CMake in our
internal package manager before I can upgrade boost. Currently, all I need
to do it write a script called from our custom build system that does
- call bootstrap
- call b2 with appropriate flags (this is the hard part)
- add the include path
- synthesize the link libraries
What's nice about this is that there are no dependencies -- everything is
completely self contained, and I like that.
For me, from a user point of view, I like things they way they currently
are. I can build boost easily in a work environment with no dependencies
when not using CMake. When I am using CMake, I can easily set BOOST_ROOT
and call FindPackage(Boost) and everything just works. I've had very few
problems with this.
I've never had to deal with boost.build in any significant way, so I can't
speak to how difficult it is. But I feel like this keeps coming up because
some people really don't like boost.build and are tying to force the change
and something the users really want when that's not actually the case when
considering the wider audience.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk