Boost logo

Boost :

Subject: Re: [boost] Library devs only: Boost v2.x distro design questions
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-10-24 19:19:31


And answering my own questionnaire ...

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

I am willing.

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

I would like a new separate Boost v2.x distro in addition to the v1.x
distro.

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

I would keep different editions of Outcome in each, with different
configuration and defaults.

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

C++ 17, as that is where surveys say the userbase is moving to from C++ 11.

> 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'd prefer the inline namespace.

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

Probably cmake. I could be convinced with Build2, if it spat out
exported targets for cmake consumption.

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

Yes I think they should. As a header only library, Outcome is very easy
to integrate into any package manager, indeed it's already built-in to
godbolt.

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

Initially speaking, I think the rolling release suits best at the
beginning. As things stabilise and mature, then proper releases seem
appropriate.

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

Definitely local HTML server. Static HTML is so 1990s.

> 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 think it should be standard choice. I know that requires a Python
installation on people's machines to build, read docs, or indeed do much
at all, but I think devs should get over it.

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

In my case, I have no hard dependencies on Boost at all. Though I'd like
Boost.Config and Boost.System ported over if possible. And maybe
Boost.Exception.

Niall


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk