Re: [boost] proposal - modularize Boost build system

Subject: Re: [boost] proposal - modularize Boost build system
From: Peter Dimov (lists_at_[hidden])
Date: 2017-06-18 17:22:54

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.

You keep wishing for that, and you keep missing the point. This is 
antithetical to the 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.

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.

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.

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.

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.