Library devs only: Boost v2.x distro design questions

newer
[parameter_python] Merge to master

Niall Douglas

24 Oct 2018 24 Oct '18

7:12 p.m.

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? 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? 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? 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? 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. 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 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? I could go on, but let's stop there for now. Niall

Show replies by date

Niall Douglas

24 Oct 24 Oct

7:19 p.m.

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

Rene Rivera

7:33 p.m.

On Wed, Oct 24, 2018 at 2:12 PM Niall Douglas via Boost < boost@lists.boost.org> 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?

I've already done it. 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?

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

Only one that works on whatever that is script generated from an entirely separate github repo outside of Boost.

...

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

C++11 as that's where the user base is at 66% of users. 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)

You forgot to also ask about macros. Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake,

...

Build2, something else?

Irrelevant.

...

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

You should watch https://www.youtube.com/watch?v=sBP17HQAQjk.

...

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.

This has been asked before and the answer has been to keep releases. Q8: Should Boost v2.x use a local HTML server to serve documentation,

...

and the static HTML docs be dispensed with as a requirement?

NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Q9: What are your feelings towards the use of Python to script

...

infrastructure and tooling in any Boost v2.x?

I wrote most of those Python scripts so I'm fine with it.

...

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

Different way to ask the previous question.. NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

...

or Python to build a release etc

We already use Python for releases etc. works fine and reliably. 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?

The build system and Predef. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

Steven Watanabe

7:35 p.m.

AMDG On 10/24/2018 01: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?

No.

...

<snip questions rendered irrelevant by Q0> In Christ, Steven Watanabe

Stefan Seefeld

7:58 p.m.

On 2018-10-24 03: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?

I'm not sure whether I'm thinking too much about implementation details here, but I expect this to imply a repo fork (or at least a separate branch) of my libraries, so I can strip off support for no-longer-supported language variants. And I assume that by "distro" you mean a set of releases built from those forks, rather than the current set of repos. Correct ? My answer is "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?

By all means, a separate one ! (Isn't the whole point to strip off legacy support ?)

...

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?

That depends on the library and the existing amount of legacy support. In either case I'd keep support for "Boost 1", at least until I get a sense that all users of the library have moved to the new "Boost 2" version.

...

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'm not sure how to interpret the question. It's possible I'd share bugfixes among both versions, but otherwise they would evolve more or less independently. (Very likely the "Boost 1" version would move into a strict "maintenance mode", without any actual development, as that would presumably move to "Boost 2" only.)

...

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

This question implies to many assumptions for me to answer in simple terms, so let me step back a little: The only way forward, *in particular* if we bootstrap a "Boost 2", would be a fully modular set of libraries. The choice of build system will be up to individual library projects, as would the choice of minimal C++ standard. Further, a particular set of flags used to produce binary releases (including what C++ standard feature is used) isn't particularly important, at least as far as the definition of the project itself is concerned. It may however be restricted by the set of standards that are actually supported.

...

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 both Boost versions to coexist in a single translation unit. Any versioned namespace seems fine, as I can alias it in user code.

...

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

None. Boost should be fully modular, and if we can't manage to do that for "Boost 1", we should at least start "Boost 2" with full modularity right from the start, and build-level requirements should be communicated in a build-system-agnostic way.

...

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

Such integration is a nice-to-have feature, but shouldn't be handled centrally. (Modularity & autonomy !)

...

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.

official releases in the long term. (Obviously, to get there and to establish a stable cadence will take time)

...

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

As previously, that shouldn't be a centrally managed concern. Documentation should be up to individual library projects.

...

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

Python ! :-)

...

For example, Python to run a local HTML server to serve documentation locally, or Python to build a release etc

These are implementation details we shouldn't be concerned with. *Please* learn from past errors and don't reinvent tools (and infrastructure) unless you absolutely have to. For now, github and its tools and support services are totally sufficient. And even if we have to move, let's not start a Big Unified Discussion On Tooling Again !!

...

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?

That's an interesting question. In the projects I'm currently involved in (Boost.Python, Boost.GIL, Boost.uBLAS) we are trying to (slowly) replace dependency on core components by C++11 equivalents (from type_traits over shared_ptr etc.), and I'm not sure what dependencies will remain once that endeavor is finished.

...

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

Stefan -- ...ich hab' noch einen Koffer in Berlin...

Robert Ramey

8:26 p.m.

On 10/24/18 12:12 PM, Niall Douglas via Boost wrote: I think this question is ill-formed. It presumes that someone (us) can determine what other people are going to do. No one has the authority or influence to do that. But what can we do then. We can provide support for those who want to restrict their choices of Boost libraries according to their own criteria. That is: a) given information about a library, e.g. which level of C++ is required, is it actively maintained and supported, etc. etc. b) show me a list of elgible libraries. c) and tell me if any on that list are dependent upon on non elgible libraries. d) decide which subset of Boost I want to use. e) download and build that subset. Presumably this subset will be compatible with each other. Let's call that a "closed compatibility subset" - or for brevity "closed subset". Now I can download, build any closed subset that captures the requirements that I have set. If I'm lazy - and I am - I could use someone elses prepared list - C++17 compatible libraries. Or C++03 libraries presumable a larger set. If I'm not lazy I might make my own closes subset - those libraries which don't required RTTI. or ... In short, rather than having the Boost organization try to make these subsets for me through some sort of review process, just help me make my own subset. Now implement "modular" boost and we're done. Libraries no longer in use are siting out there somewhere - but who cares - they're not polluting anyone's universe. The whole problem just becomes a non problem. No committees, no discussion, no pain, no deprecation, no discussions about replication, no boost policy regarding library support, no discussions about what boost policy regarding library support. no wasted time - all for the cost of a little bit of "wasted" disk space. Wouldn't that be heaven? Now the only thing we need to do to get all of these benefit is to make it easier to use a subset of the whole of boost. That is Boost Modularization. In order to do this we need: a) Consensus that this is necessary and valuable. b) More detail on what has to be done to achieve this. A c) Some implementations. Amazingly, slow progress is being made on all three fronts. I've very hopeful for the future! Robert Ramey

Niall Douglas

25 Oct 25 Oct

8:36 a.m.

...

I think this question is ill-formed. It presumes that someone (us) can determine what other people are going to do. No one has the authority or influence to do that.

It's a question of there being a consensus, and if not, a sufficient critical mass. What I saw there before is the usual complaints as we've seen here for a decade now, the usual suggestions for solving it, and the usual lack of anybody actually doing anything. Which is just pointless noise. So I made that questionnaire to see who would publicly go on record with where they are currently at. There is obviously no consensus, though I note with excitement how many fewer naysayers to real change there are compared with even three years ago. So clearly things are shifting, and I note a number of people whose opinion has transformed radically from where they were only recently. That means that if somebody did roll together a tighter, smaller, more focused Boost 2.x distribution of the better quality libraries, it might have legs. Up to you Boost! Niall

Edward Diener

24 Oct 24 Oct

9:01 p.m.

On 10/24/2018 3: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?

I have less than zero interest in forcing Boost libraries to adopt some arbitrary C++ standard. I can understand only one thing, as evidenced by my cxxd library which nobody liked as a solution, that it would be helpful for a library which uses a Boost library rather than the C++11 equivalent library to use the C++11 equivalent library instead and therefore drop support for C++03. Beyond that forcing some library to use some C++11 on up construct, just to adopt some arbitrary C++ standard, is lunacy.

Vinnie Falco

9:14 p.m.

On Wed, Oct 24, 2018 at 12:13 PM Niall Douglas via Boost wrote:

...

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

I will literally do anything if it means another GitHub star. Regards

Edward Diener

10:06 p.m.

On 10/24/2018 5:14 PM, Vinnie Falco via Boost wrote:

...

On Wed, Oct 24, 2018 at 12:13 PM Niall Douglas via Boost wrote:

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

I will literally do anything if it means another GitHub star.

Are you sure you are not secretly a chef and meant Michelin instead of GitHub ?

...

Regards

Andrey Semashev

10:31 p.m.

On 10/24/18 10: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?

I don't know what you mean by "any v2.x distro", let alone by "adapting my library", so in this broad wording the answer is no.

...

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?

Again, it depends on what you mean by "v2.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?

If there happens, let's say, a fork of Boost, I will definitely keep maintaining only one copy of each of my libraries. If there is no fork and Boost simply increments its major version number, I will keep maintaining my libraries as before.

...

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

There shouldn't be one imposed by Boost. If nothing is specified, let it be the compiler default. Otherwise, let the users (or packagers) decide what C++ version they want. Of course, Boost maintainers are free to decide which C++ versions they want to support.

...

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 implementation doesn't really matter, but the fork must not conflict with the current Boost. Otherwise it will be a major pain for the users. But given that I don't intend to maintain two copies of my libraries, either the libraries will not be part of the fork, or someone else will have to perform the maintenance in the fork. If there is no fork but just a new major release of Boost then I don't see the reason to change namespaces or macro names.

...

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

Something portable and capable enough to support Boost's needs. Popularity is a plus, but not a defining factor. Otherwise, I don't really care.

...

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

No, none. Packaging should be done separately from the general maintenance, most likely by different people than maintainers. I'm willing to accept bug reports and patches from packagers about the code and build scripts, but not regarding packaging.

...

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.

I think, official releases are good for packagers and many users. Not everyone can or want to update every once in a while to a random revision from git. Also, I don't believe there will ever be a point when 150+ libraries all pass 100% CI tests. Even with just one library I often get spurious failures. Note that I don't mind releases of specific libraries on their own. I'm just saying that bundled Boost releases are still very much useful.

...

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

Online documentation is a must, if that is what you mean. I don't really care how it is served, as long as the docs are reliably available.

...

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

If this is a question about online server infrastructure then I don't care, as long as it works reliably and with acceptable performance. If this is about my local system where I build stuff then no HTML servers or other fancy services please. When I build docs, I want to get a bunch of html files lying in some directory, that's it. How I view it is my business, and if I want to I will bring up an HTTP server myself.

...

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?

I use many Boost libraries, too many to list, some of them are in the standard library as well. Boost.Intrusive, Boost.Container, Boost.ASIO, Boost.Interprocess, Boost.Atomic, Boost.Spirit v2 to name a few off the top of my head. I'm not sure what you mean by "porting".

Robert Ramey

25 Oct 25 Oct

1:31 a.m.

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

Robert Ramey

1:49 a.m.

On 10/24/18 6:31 PM, Robert Ramey via Boost wrote: My real point here Nail is that you're conflating two separate issues. Library development, design, and maintenance with library deployment. You could relatively easily deploy a "closed" subset of boost which was "cleaner" or simpler, or whatever just by selection. It would achieve everything you've wanted to achieve: a) exclude libraries no longer maintained. b) exclude libraries which are not compatible with newer libraries (I don't think any of these exist) c) exclude libraries which do not provide, in your humble opinion, any useful functionality. Think bigger. You could create a special deployment of Boost for students which would a closed subset which one could start to use much faster than being confronted with the whole of boost and standard library. Think bigger yet. Create a deployment for beginners in C++. Call it: "Boost for Dummies" This may sound funny, but I don't mean it to be. I see the idea of creating "curated" Boost/C++ deployment as being a really useful and valuable idea which doesn't require that all the boost "cats" to be harnessed to the "next big thing" which ain't going to happen. This single most valuable step to this goal would be to cajole the maintainers of the libraries to create documents in BoostBook if they don't already. I don't know how many are left. But that "Might" and the one's that aren't are likely so old you wouldn't want them in your "Boost for Dummies" anyway. Boost book can be rendered with great flexibility and it would be possible to craft a beautiful publication quality book that would be really useful to a lot of people. I can see it now: C++/Boost for Dummies by Nial Douglas - Principle Architect of Boost. So I think I see where you're trying to go with this. And I see the merit in it. But if you approached in the way I suggest, I think it might be more likely to get you what you might be seeking. Robert Ramey

Antony Polukhin

6:59 a.m.

On Wed, Oct 24, 2018, 22:12 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?

At most half of them. 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?

One distro please. 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'll keep the remaining half of the libraries in both Boosts. The defaults will be different. I'll keep maintaining all the libraries. Q3: What C++ standard should Boost v2.x's master build system be

...

defaulted to? C++ 11, 14, 17 or 20?

17 at least. 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)

It should be namespace boost { inline namespace v2_VERSION { }} where VERSION is the minor version of current release. Many people were complaining that they have to use two different versions of Boost. Different versions do not link well. Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake,

...

Build2, something else?

The most popular ones. Cmake leads right now. Q6: Should Boost v2.x's libraries auto integrate individually into some

...

package manager? If so, which ones do you intend to support?

I'd leave the packaging to the package manager authors. We have other things to do, rather than supporting 5-37 different package managers. 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.

Same as with Boost1 Q8: Should Boost v2.x use a local HTML server to serve documentation,

...

and the static HTML docs be dispensed with as a requirement?

Don't care. 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

Python is a good language. 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?

Asio, intrusive, container, program_options, spirit, predef... too many to enumerate all of them. I could go on, but let's stop there for now.

...

The idea of Boost2 is a good idea. But let's move evolutionary, rather than revolutionary. Deprecate and remove the libraries, set cxxstd=14 by default, mark outdated/unmaintained libraries with some mark in the docs, add inline namespaces with version, add modules ts support... In a few years we'll be able to change the major number to 2.

...

Hans Dembinski

8:21 a.m.

...

On 24. Oct 2018, at 21:12, 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.

Since boost.histogram was accepted (conditionally)….

...

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?

I didn't follow the discussion enough to understand the question.

...

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?

There should be only one official version of the library, so Boost v2.x exclusive.

...

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

C++14.

...

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)

inline namespace.

...

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

cmake.

...

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

Yes.

...

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.

Rolling releases.

...

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

No preference.

...

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

Python is awesome and becoming the de-facto default scripting language. More Python please.

...

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?

core, callable_traits, multiprecision PS: Excellent comments by Vinnie and follow-up by Edward. Lol.

Mateusz Loskot

9:02 a.m.

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

Paul A. Bristow

26 Oct 26 Oct

11:03 a.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] 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 +44 (0) 1539 561830

2207

Age (days ago)

2209

Last active (days ago)

List overview

Download

16 comments

12 participants

participants (12)

Andrey Semashev
Antony Polukhin
Edward Diener
Hans Dembinski
Mateusz Loskot
Niall Douglas
Paul A. Bristow
Rene Rivera
Robert Ramey
Stefan Seefeld
Steven Watanabe
Vinnie Falco