Subject: Re: [boost] proposal - modularize Boost build system
From: Chris Glover (c.d.glover_at_[hidden])
Date: 2017-06-19 20:18:13
On Mon, 19 Jun 2017 at 15:39 Stefan Seefeld via Boost <boost_at_[hidden]>
> I also want to be able to pick my own build (etc.) tools, not in
> addition to Boost.Build, but instead of it. I understand that right now
> that's not supported, which is why I'm writing this proposal. What would
> it take for Boost to support individual libraries to be built with
> anything else ? What requirements would that "anything" have to meet,
> and how would it interact with the existing infrastructure to work ? Is
> that such a strange request ?
I strongly disagree with allowing that to happen.
I'm a fan of the current model of distributing boost because of how I've
seen it distributed at large companies.
Every company I have worked at has maintained their own custom, internal
build system. To integrate boost into any of those systems has been pretty
easy -- it involves writing a script to bootstrap, invoke b2, copy headers
and libs and possibly generate some synthetic targets to let the custom
build system know how to find boost.
In some cases I've had to modify boost build to support weird proprietary
compiler variants -- which was a pain -- but imagine if every library was
doing their own thing? Now in order to use your library, I need to get
approval for the licence on the build system, then I need to make the build
system work and integrate it with whatever our custom setup is. Then
possibly I need to patch it to work with whatever special compiler we're
currently using, and I need to potentially do that more than once.
For me, the simplicity of monolithic (or at least unified) boost is worth a
huge amount and I would really hate to lose that. I feel the same about the
licensing issue that came up a few weeks ago for the same reasons --
getting approval to use and distribute boost at a large company is vastly
simpler if things are consistent.