Re: [boost] proposal - modularize Boost build system

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

On 18.06.2017 13:22, Peter Dimov via Boost wrote:
> Stefan Seefeld wrote:
>> At present, building a Boost library requires the entire
>> (super-)repository to be checked out, and the build logic itself
>> involves traversing the entire source tree, looking for a "Jamroot".
>>
>> What would be beneficial to many would be a workflow like this:
>>
>> 1) Have a development environment with (some version of) Boost
>> pre-installed (or at least the parts that the library being built
>> depends on).
>>
>> 2) Check out a single Boost repository (e.g.,
>> https://github.com/boostorg/python)
>>
>> 3) Invoke a command to build it (if there is anything to build)
>>
>> 4) Invoke a command to test it
>
> It's actually possible to do this with Boost.Build, but I want to talk
> about something else here.

Can you elaborate ? "Possible" in the sense of "it just a matter of some
programming" ? Or am I missing something ? The last times I asked
(specifically for the Boost.Python project) I was told some of the
required functionality was being worked on (on some Boost.Build
development branch), but wasn't actually neither on "master" nor "develop".

> You keep wishing for that, and you keep missing the point. This is
> antithetical to the original Boost spirit.

Sorry, not sure what "the point" is in your reply. And not sure why you
mention the "original Boost spirit". I'm not asking what it takes to
conform to some spirit or other, I'm asking whether a specific use-case
that is obviously important to me (and to many others I gather, even
though few people express it the way I do) could be supported. Are you
telling me that it can't, because it's not in line with some "original
Boost spirit" ??

> The idea of Boost is that you test your library not against the last
> Boost release, or against whatever old Boost release happens to be
> installed. The idea is that you test against the current development
> state, which today means the develop branch.

While I think that this is a problem in its own (which we could argue
about in a separate thread), let me clarify: I'm not suggesting that the
current workflow should be abandoned. I'm asking for another workflow to
be supported. I think both can coexist if that is useful.

> Yes, this makes things less convenient for you, because it means that
> people's changes break your build. This is on purpose. It is how Boost
> has achieved its track record of stability and quality.

I'm not worried about stability (as far as Boost.Python's prerequisites
are concerned, at least). I'm worried about scalability. It just doesn't
work. Or it works badly.

> This is part of the price you pay for being accepted as part of Boost
> - the duty to act as an integration test for your Boost dependencies.
> This is beneficial for you in the long term, because you can detect
> breaking changes in your dependencies before they get shipped. If you
> only test against 1.56, and 1.64 breaks your library, you won't hear
> about it before 1.72. This does you no good, and it does your users no
> good. You WANT to know if changes in 1.65's SmartPtr would break you
> BEFORE 1.65 gets released.

I'v replicated this paragraph and answered in a separate thread, to keep
this discussion on-topic.

> This is not theoretical. At one point in the past, certain changes in
> enable_shared_from_this would have broken Boost.Python. Without it
> being there to catch this fact, they would have went into a release,
> because nobody else was affected.

I understand, and appreciate the role downstream projects have as
"integration tests" for Boost libraries.
Again, I'm not saying this isn't useful to do. I'm asking for support
for a separate workflow.

>
>
> TL;DR Boost is tested as a unit, which ensures higher quality. This is
> deliberate. It's not a bad habit that needs to be broken.

I understand and disagree. "Boost as a unit" just doesn't work any
longer. I think it's possible to support the kind of integration testing
you have in mind, while at the same time break up Boost into more
autonomous components.

        Stefan

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