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@lists.boost.org> 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