Re: [boost] proposal - modularize Boost build system

Subject: Re: [boost] proposal - modularize Boost build system
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-06-18 17:51:19

On 6/18/17 10:22 AM, 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.
> 

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

Wow - I don't get this at all.

> 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.

I've think this is a very bad idea and creates lot's of problems.  I've 
advocated for years that we should not do this.  I've pulled back on 
this for the last few years because:
a) I can't convince anyone else I'm right
b) Since git let's me easily select master branch for the boost 
libraries I'm not working on I can easily and unobtrusively test against 
the latest release. So the problem doesn't concern me personally any more.

> 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.

LOL - not because of that but in spite of that.

And what are users expected to do? One thing that gets a little lost in 
this discussion is the distinction between boost library developers and 
users of boost libraries in their current applications.  I think some of 
the CMake motivation is to help our users.

> 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.

yada, yada, yada.

Testing is an experiment.  If you change all the variables at once it's 
an uncontrolled experiment and the results are useless and often 
misleading.  Change one variable at a time - your code.

> 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.

Depending on source code from one library build to be the test of 
another library is not really a test.

> 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.

This means were testing against implementation rather than 
specifications.  It lowers the standard of quality by permitting the 
argument "well it passes the test" to be an argument.  It is actually a 
dis-insenetive for developers to write more tests.  The more tests you 
write the more you get bogged down in other persons poor code. It's part 
of the motivating for those who want to diminich library dependencies 
even to the point in importing source code from other libraries into our 
own distribution.

But the fundamental problem is that it doesn't scale.  Boost cannot grow 
if the whole damn thing has to be released as a unit.

Robert Ramey