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

Subject: Re: [boost] Library devs only: Boost v2.x distro design questions
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2018-10-25 09:02:36

Without trying to infer purpose, discuss validity or well-formedness
of your question,
I'm going to simply answer them as well as I can understand their plain text.

On Wed, 24 Oct 2018 at 21:12, Niall Douglas via Boost
<boost_at_[hidden]> wrote:
>
> Splitting this off from the other thread, can I get feedback from Boost
> library maintainers ONLY. Not users, not non-maintainers.

I'm member of Boost.GIL and Boost.Geometry.
Lately, I've been less active for the latter though, but I'm interested
in helping for any necessary modernization.

Disclaimer: I speak for myself, and not for GIL or Geometry team.

> Q0: Are you willing to do the work to adapt your library for any Boost
> v2.x distro if it were to happen?

Yes.

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

New, in Boost master and develop, w/o looking back, but drawing fat thick line.
I have no interest in maintaining anything pre-C++11 or pre-C++17,
depending on the language version Boost decides to jump for.

(I assume you mean distro as the "source distribution" as explained
by eg. http://wiki.civiccommons.org/Releasing_Open_Source/)

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

Move exclusively to Boost v2.x.
Orphan Boost v1.x.
(Unless the 24/7 time allowance becomes 48/7).

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

C++11 or C++17

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

I don't expect or want to allow boost::v1::gil and boost::v2::gil be
used in the same unit.
Just namespace boost - fat thick line!

> Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake,
> Build2, something else?

Boost.Build and CMake, both first class citizens.

Hyper-ideally, Boost.Build port to Python and CMake.

> Q6: Should Boost v2.x's libraries auto integrate individually into some
> package manager? If so, which ones do you intend to support?

No.

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

The managers - the collection is too large to let it roll itself.

> Q8: Should Boost v2.x use a local HTML server to serve documentation,
> and the static HTML docs be dispensed with as a requirement?

https://www.youtube.com/watch?v=umDr0mPuyQc

> Q9: What are your feelings towards the use of Python to script
> infrastructure and tooling in any Boost v2.x?

I like Python a lot.

> For example, Python to run a local HTML server to serve documentation locally,

https://www.youtube.com/watch?v=umDr0mPuyQc

> or Python to build a release etc

Fine.

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

libs/config
libs/core
libs/concept_check
libs/test

> I could go on, but let's stop there for now.

Please.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net