Subject: Re: [boost] Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's community*
From: Joseph Van Riper (fleeb.fantastique_at_[hidden])
Date: 2016-05-20 05:32:38
I rarely contribute anything to boost, unfortunately, but maybe you might
find my input on this topic worth considering.
RE: Monolithic boost...
This has worked okay for me. For a new boost release, I download the
monolith, compile according to our standards, and make that release
available to others on my team for integration with the rest of the
product. I try to keep it up to date, to resolve any possible bugs, get
new features, etc.
RE: C++14 adherence...
We have a peculiar problem here. We need to be able to compile our code on
compilers that are about 10 years old. I want to use the spiffy-great
features of the latest compiler specifications, but can't due to this
constraint. Insisting that we can use a newer compiler won't work; our
customers specifically use old operating systems because they have security
flaws about which they wish to teach, hence why our software must work on
older OSes, and why we have to support older compilers (the ones that were
available on these OSes). I've already tried compiling newer versions of
g++ on some of these with varying degrees of success.
So, at least to our use case, we hold as valuable the idea that at least
some parts of boost not progress to exclude old compilers. We need that
If one makes a separate distribution that only provides C++14 support,
that's fine, but any idea that involves dropping support for older
compilers altogether would require we stick to older versions of the boost
distribution. That may limit the degree to which we will benefit from the
collection, or any improvements made to it.
I once thought it might be valuable to ascertain which libraries I use,
pull those bits out, and set up a reduced subset of the boost collection to
just what we actually use in our product to help reduce how much of the
collection we compile, etc. It's fantastically difficult to achieve, and
in the end, I don't think it is worthwhile. By doing so, I would
discourage the exploration of other parts of the library my team might find
useful. Consequently, I don't bother. I just make the whole thing
available to the team, and let them choose what they wish to use, absent
the bits that we simply cannot use due to our requirement that we have to
compile on ridiculously old compilers.
I hope this information on how one small team of developers use this tool
is useful to you. I'd be happy to answer any questions, if you'd like, on
our use of boost if it would help guide your collective efforts.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk