Re: Boost downloads and JFrog

From: Robert Ramey (ramey_at_[hidden])
Date: 2024-01-12 02:16:05

On 1/10/24 6:38 AM, Vinnie Falco via Boost wrote:
> On Tue, Jan 9, 2024 at 11:49 AM Robert Ramey via Boost <
> boost_at_[hidden]> wrote:
> 
>> Perhaps it's time to "get serious" about Boost "Modularization".
> 
> 
> This statement ignores all the work that has been done and continues to be
> done in terms of making Boost modular.

Just the opposite.  It acknowledges the work done and implicitly laments 
that it has failed to arrive at its logical conclusion.

What is the purpose of investing the effort into "Boost Modularization" 
if it's not this?

> 
> 
>> Basically this would mean that users download just the libraries (and
>> their dependencies) they actually intend to use.  Of course this would
>> be a big project.  But we've been working hard to try to move in this
>> direction.
> 
> 
> Yes, we have "been serious." (And note when I say "we" I exclude myself, as
> I have just been busy cranking away at producing individual libraries and
> supporting Boost Libraries infrastructure).
> 
> 
>> This would in practice eliminate the concept of Boost version 1.84
>> etc... and replace with Boost Serialization library version 1, ...
>>
> 
> Grouping all the libraries together into a single release version (e.g.
> 1.85.0) which is all tested against each other as a unit, is the only sane
> development model. Otherwise we run into the combinatorial explosion of
> questions like "what version works with what." 

Actually, I believe this statement is exactly wrong.

a) Treating Boost "as a unit" and testing on this basis results in an 
amount of work which increases with the square of the number of libraries.
b) Modifying libraries to pass tests in other libraries make one library 
dependent on another which might not be obvious.  Libraries should be 
tested individually as a unit to prove that the the implementation of 
the library matches faithfully implements it's expored interface.
c) If this is done, it is guaranteed that errors cannot be introduced 
when libraries are composed.
d) Libraries interfaces including type requirements should be formally 
documented and tests should certify that the implementation is 
consistent with the interface.
e) If the above is done - the amount of testing will increase only 
linearly with the number of libraries.
f) Adding one more library should not provoke any new errors.
e) Introducing an error into a library should be detected during unit 
testing and if inspite of this it's undetected, it will only affect 
other libraries which import the header from the erroneous library.
g) Library authors should strive to detect at compile time (preferibly) 
or runtime which interface requirements are not met.  Boost testing has 
special facilities "test compile fail" specifically to facilitate that.
h) The need to "test all the libraries together" is a red flag/code smell.

In any case, users should be able to download any number and/or 
combination of libraries (along with their dependencies) and use just 
that.  This will avoid making uses applications more complicated than 
they already are.

And furthermore,
> "eliminating the concept of Boost version ${X}" pushes more testing and
> documentation work (to explain what versions work with what) onto each
> individual author instead of centralizing that effort into the release
> process. I don't like this at all.

Right - Wrong !  If we need to specify that information - we've already 
made a mistake. No one can keep all those combinations in their head. 
If some library/app depends on some other library subject to some 
dependency of compiler level, etc. and that requirement is unfullfilled, 
It should result in a compile time error.  Our config library - a 
masterpiece by John Maddock - is designed to address this very problem 
and does so very well.

> 
> Boost would migrate from being a single/monolithic library to a group of
>> libraries with some explicit dependencies (on other boost librarys,
>> standard library or ?).

It might.  I can't predict the future.  Nothing in this proposition 
precludes a "complete release".  But it should be an option - not a 
requirement.
>>
> 
> Boost is already a "group of libraries with some explicit dependencies." It
> just so happens that they are bundled together into one archive. Whatever
> it is that you are proposing would be in addition to and not in lieu of
> what we have.

Sure.  But if we finished the "boost modularization", the "global" 
release would be nothing more than the union of the individual ones and 
guarenteed to be correct.

>> The fact that we can't do so now is a symptom that our development
>> practices need work.
>>
> 
> I think this is overlooking the fact that the Boost release process *works
> well* right now. Three releases every year like clockwork and they are
> pretty high quality in terms of having minimal inter-library defects.

I don't dispute this.  But - it doesn't scale and can never scale. 
That's what started this discussion in the first place.

I'm aware that significant effort has been invested into the "boost 
modularization" effort.  I have a couple of questions about this effort.

a) what is the point of this "modularization" effort if not this?
b) what this the desired/expected benefit of this effort if not this?
c) when will we know when it's done?
d) how will we know whether or not it's been successful?

>>
>> Robert Ramey
>>
>>
>>
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
> 
>