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

Subject: Re: [boost] Library devs only: Boost v2.x distro design questions
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-25 01:31:27

On 10/24/18 12:12 PM, Niall Douglas via Boost wrote:
> 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?

any ?  hmmm - couldn't promise that.
> 
> Q1: Would you prefer a new, separate Boost v2.x distro in parallel to
> the v1.x distro, 

no

or to keep everything within one v1.x distro?

Just cherry pick the boost libraries you want use in your v2.x fork. You 
don't even have to aske me.
> Q2: Would you be intending to keep your library inside Boost v1.x, 
yes
move
> it exclusively to Boost v2.x,
no
  or have it exist in both Boost v1.x and
> v2.x but with different defaults configured?
as I said, just create your own fork.  You can
a) post PRs to the "golden copy"
b) change whatever you want
c) Merge changes in the "golden copy" back into your fork before you 
"release" or whenever convenient.

> Also, would the version in
> v1.x be hard forked from any v2.x edition i.e. the v1.x edition would
> get orphaned?
no - you or anyone else can fork from it for any desired reason.  The 
golden copy in my case will always be compatible with all versions of 
C++03 .. ?  Of course if you want to use it as part of an application 
you'll have to compile your copy with the same compiler your application 
is using.  You're totally free to do that and can expect it to work.

> Q3: What C++ standard should Boost v2.x's master build system be
> defaulted to? C++ 11, 14, 17 or 20?
whatever you want.  It's still a free country.

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

The golden copy will use the current namespace.  If you wanted you could 
probably wrap the headers to effectivly change them.  But if I were you 
I wouldn't do that as it would entail nothing but grief.  Another thing 
you could it is just global replace all the namespace names boost to 
boostv2.  Remember (I believe) you'll always be able to merge the golden 
copy back into your local one.

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

whatever works best for you.

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

again. whatever works best for you.  Were you to conjure up something of 
value in boost v2 - and we ask you to do it - feel free to create a PR 
so we can use it in the "golden copy"

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

again whatever works best for you.  feel free to experiment.

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

you could do that on v2 however you want.  This question is actually 
interesting however.  Personally I've advocated that every library have 
statically defined BoostBook or quickbook documentation and from that 
generate on demand documentation in html, singlepage html, and PDF using 
the boostbook system.  I've also argued that the static web pages built 
either by hand or via the boostbook system should be part of the 
library.  My main reasons are modularity and regularity as not all 
documentation is made with boostbook.  This is historically a stick 
subject and will continue to be.

> 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

oh - one more language to learn - just to release.  No thanks. I'm kind 
of busy.

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

mpl, iterators, sprite, and likely a lot more.
> 
> 
> I could go on, but let's stop there for now.

You're welcome.

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