Boost logo

Boost :

Subject: Re: [boost] proposal - modularize Boost build system
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-06-19 15:46:26


On 19.06.2017 10:59, Peter Dimov via Boost wrote:
> Stefan Seefeld wrote:
>
>> I have no idea why you are mentioning all this. How often do I need
>> to repeat that this proposal is about modularization, not about
>> decoupling the release process of individual Boost components ?
>
> All right. What, specifically, do you want further modularized? Did
> you even read what I wrote in my other posts?

I did, yes. Sorry for not specifically acknowledging that. I know about
these tricks (I use something similar to set up my Boost.Python CI
environment), but consider them hacks as they don't really solve the
fundamental requests, which are:

* I want to be able to build a given Boost library stand-alone, with
nothing but the library's repo being checked out. (In other words:
prerequisite Boost components should be assumed pre-installed.)
* I want to be able to choose the build (, test, etc.) infrastructure
used for my library, and make sure that when Boost is built as a whole,
that build infrastructure is used.

I can't stress this enough: this second point is to 99% non-technical.
It's about letting project maintainers decide how they develop (build,
test, etc.) so we don't have to have these "lets all switch from tool A
to tool B" discussions any longer. The choice between b2, cmake, scons
should be done per project, rather than the whole Boost organization at
once. The only technical aspect of this is the definition of the
interface between super-project and sub-project, i.e. the mechanism by
which Boost.Build invokes the library-specific build systems for those
of us who want to continue building Boost as a whole.

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk