Re: [boost] proposal - modularize Boost build system

Subject: Re: [boost] proposal - modularize Boost build system
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2017-06-19 18:48:58

On 19.06.2017 13:00, Peter Dimov via Boost wrote:
> Stefan Seefeld wrote:
>> > On one hand, you want to use the system Boost.Build, and on the
>> other, > your Jamfiles depend on features that aren't present in it.
>> This simply > cannot work, your desires are contradictory.
>>
>> Not sure what your point is. I think it's perfectly normal that on
>> some platforms the default (system) version of a package is too old,
>> so a newer version needs to be pulled in from another repo
>> ("testing", perhaps ?). That doesn't invalidate my desire to work
>> with system packages though, rather than development versions.
>
> My point is that the reason it doesn't work is that your Jamfiles are
> using features not present in the system Boost.Build.
>
> You were complaining that we need to make it work. But there's no
> deficiency to be addressed here. It already works.
>
> So what's the complaint?

I'm not "complaining", I'm *proposing* an architectural change. Again:

As a boost library maintainer I want to decouple my library from the
rest of Boost to be able to

* build it as a unit (i.e., with everything else being fixed as a
prerequisite, rather than being built on-the-fly)
* use tools of my own choice to build, test, package, issue-track,
document (etc., etc.) my library, so we won't need to agree on this
scale whether to use tool A or tool B. (Recall the question triggering
this proposal was the proposal *for the entirely of Boost libraries* to
switch from Boost.Build to CMake.)

I'd be more than happy to learn that this is already possible, at which
point I'd write an article (a wiki page, say) to document how to do it.
So let's assume that creating a "Jamroot" file in my library's root
directory is all it takes to let b2 build my library stand-alone.

Then what about the second point, which was:

> 2) Define a clear interface the outer build logic will use to invoke the
> nested build commands.

In other words, what does that Jamroot file need to contain at a
minimum, to satisfy the global build processes (i.e., the ones used to
build Boost as a whole, including building release docs etc.) ? There
are globally called rules such as "boost-install", "boostrelease", etc.
that seem to be required. And what about parameters such as build
variants or toolchain versions ? How can I intercept those such that I
can call my own (local) build logic ? Is that documented anywhere ?

        Stefan

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