Re: [boost] Library devs only: Boost v2.x distro design questions

Subject: Re: [boost] Library devs only: Boost v2.x distro design questions
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2018-10-26 11:03:22

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Niall Douglas via Boost
> Sent: 24 October 2018 20:13
> To: Boost Developers List
> Cc: Niall Douglas
> Subject: [boost] Library devs only: Boost v2.x distro design questions
> 
> Splitting this off from the other thread, can I get feedback from Boost
> library maintainers ONLY. Not users, not non-maintainers.
> 
> Q0: Are you willing to do the work to adapt your library for any Boost
> v2.x distro if it were to happen?

NO!

The work maintaining any separate distro is out of the question as far as I am concerned.

We have discussed this endlessly before.  Boost.Math is by far the largest library in Boost with the most tests.  It is written, for
history reasons, needing C++03 and this will probably continue.  C++03++ etc features are not used gratuitously, but anything that
is supported by the leading compilers is on the menu if there is a good reason. For math special functions and stats distributions,
new language features rarely off much benefit in performance, though some readability may be improved.  It is entirely header only,
so no linkable libraries must be built.

Boost.Math's organ grinder will very probably have a similar view ;-)

> Q1: Would you prefer a new, separate Boost v2.x distro in parallel to
> the v1.x distro, or to keep everything within one v1.x distro?

If people want to maintain the current mainly c++03-ish  state, they should freeze on a particular Boost release (and do their own
patching if a particular bug fix applies to them).

> Q2: Would you be intending to keep your library inside Boost v1.x, move
> it exclusively to Boost v2.x, or have it exist in both Boost v1.x and
> v2.x but with different defaults configured? Also, would the version in
> v1.x be hard forked from any v2.x edition i.e. the v1.x edition would
> get orphaned?

 > Q3: What C++ standard should Boost v2.x's master build system be
> defaulted to? C++ 11, 14, 17 or 20?

We should stick with the long established What You See Is What You Get  ( and by see I mean "consult the regression matrix to see
what a particular library and feature work OK").

And also the ultimate test SISAS (Suck It And See) still applies.
 
> Q4: Should Boost v2.x use a boost2 namespace, or namespace boost {
> inline namespace v2 { }}? (This affects whether Boost v2 and v1 editions
> of your library can be used within the same translation unit)
> 
> Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake,
> Build2, something else?

Boost.Build - have you looked at the Boost.Math jamfiles?
CMake can run b2 - but this is only really useful for test.

> Q6: Should Boost v2.x's libraries auto integrate individually into some
> package manager? If so, which ones do you intend to support?
> 
> Q7: Should Boost v2.x have official release versions done by release
> managers, or should it be a rolling release of "whatever last passed the
> CI @ 100%"? Note that you can have this, and have official release
> versions of "especially known good" editions too.

No release of Boost.Math has ever passed all tests of all functions with all compilers, and I believe that it never will.  
That doesn't mean this is not exceedingly useful and very, very widely used.

> Q8: Should Boost v2.x use a local HTML server to serve documentation,
> and the static HTML docs be dispensed with as a requirement?
> 
> Q9: What are your feelings towards the use of Python to script
> infrastructure and tooling in any Boost v2.x? For example, Python to run
> a local HTML server to serve documentation locally, or Python to build a
> release etc.

I don't speak Python, and my brain is full :-(.
 
> Q10: What parts of core Boost are you utterly dependent upon, and would
> absolutely need ported to any Boost v2.x as no STL alternatives exist?

Sorry but this is a fundamentally flawed idea, applicable only to tiny (but often fiendishly difficult) libraries only. Boost covers
much more, and should continue to do so.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]