Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Gary Furnish (gfurnish_at_[hidden])
Date: 2017-07-27 18:42:36
On Thu, Jul 27, 2017 at 10:30 AM, Edward Diener via Boost
> On 7/27/2017 11:28 AM, Gary Furnish via Boost wrote:
>> On Thu, Jul 27, 2017 at 8:40 AM, Rene Rivera via Boost
>> <boost_at_[hidden]> wrote:
>>> Since you are making a variety of accusations..
>>> On Wed, Jul 26, 2017 at 11:01 PM, Gary Furnish via Boost <
>>> boost_at_[hidden]> wrote:
>>>> I've observed from the outside that basically no one was ever
>>>> going to touch boost.build because the people who like it (who happen
>>>> to be single points of failure for the entire boost ecosystem)
>>>> basically out-shouted everyone whenever a technical discussion came
>>> Prove it.
>> Sure. See the discussions where if you aren't doing things the
>> boost-build way and are instead a config-per-directory way your
>> basically considered a second class citizen in spite of that being the
>> way the rest of the oss world works.
> Please give a URL to these discussions you are citing. Granted that Boost
> Build creates output in a different structure than CMake does, where you get
> the rest of your complaint I do not know.
I don't have a specific discussion so much as the feeling that in
discussions leading up to the SC there was a very us against them
mentality on the part of people who like boost.build. Its not a very
welcoming place to comment as a user/minor bug fix contributor.
>> The fact that it is still
>> non-obvious how to do this without touching anything besides a build
>> directory is awful. This should be somewhere in big bold letters.
>>>> Its not like there haven't been concerns about boost.build for
>>> All build systems, heck all software, has "concerns".
>> Yes but the issues that I'm talking about are things that have been an
>> issue for years and never got fixed. See also silently dropping flags
>> if you use a space and don't quote in bjam files (something also not
>> obvious and yet important to pass compiler flags!). At least
>> CMAKE/most sane build systems will put up errors somewhere along the
> Are these so-called issues documented anywhere in Boost Trac ? Have PRs been
> created for these issues ? Have these issues been discussed on the Boost
> mailing lists ? If so, please cite where.
I have no idea, but I know that they come up enough that build
questions are pretty persistent on stack overflow compared to other
c++ software in my opinion. Boost has by far the hardest to
understand system as a user of anything I've dealt with, including
setting up cross compiling gcc which is no picnic.
I have seen the whitespace issue dismissed as intended behavior
because of the way the lexer works in a thread at one point, but its
an intended behavior that is very user unfriendly.
>>>> Its not like the documentation for boost.build wasn't
>>>> basically "ask the mailing list or prey someone else has asked stack
>>>> overflow" for years.
>>> The documentation is bad compared to what other documentation?
>> The documentation is bad compared to say, CMAKE, which isn't great in
>> the first place.
> CMake docs are just a list of various subjects without any overviews of how
> to use anything. I do not call that better than Boost Build, and I do not
> thing that Boost Build documentation is great either.
Yes but plenty of people have written CMake tutorials. Boost.build not
>> Setting up an out of build directory has always been
>> a pain with poorly documented flags needing to be invoked to share a
>> common source directory (and its worth noting that I'm not sure its
>> technically parallel safe in any reasonable way given the need to
>> bootstrap and create header links and what not).
>>>> Its not like every time a new version of MSVC
>>>> beta comes out boost.build doesn't break and its not a priority
>>>> because the maintainers of boost.build don't use MSVC.
>>> Prove that it wasn't a priority. Considering that the last Boost release
>>> was delayed precisely to support MSVC building.
>> It was delayed to support the final release. CMAKE supported it from
>> the first beta. Given that MSVC is specifically making an effort to
>> implement features to be part of the standards process, this is
>> basically a choice between using boost or being on MSVC's and C++
>> cutting edge. Support for MSVC has basically always been this bad as
>> far as I remember. It should have never been necessary to delay a
>> release to support a key platform when there were four betas.
> Four betas that were in constant flux but you think that it is up to Boost
> to constantly follow VC++'s changes as they roll out a new release over an
> extended time period. Boost has constantly gone out of its way to
> accommodate Microsoft and VC++. Any breakage that occurs is because VC++ has
> always been behind gcc and clang as far as C++ standards compliance.
> Needless to say the VC++ preprocessor has never been C++ standards compliant
> and lack of such things like two-phase lookup has repeatedly broken C++
> standards compliance in the sort of corner cases which advanced C++ code as
> evidenced by Boost libraries entails. You are way out of line on this item.
> If you had any real knowledge of Boost library code you would know that the
> vast majority of one-off fixes are for the VC++ compilers. That has
> certainly improved with the latest VC++ release(s), but to say that Boost
> does not and has not gone out of its way tro accommodate VC++ is just
Honestly standards compliance errors are great, I can fix those
locally. If I could persistently get to those I would be happy. What
has always been a problem is when feature detection or compiler
detection goes wrong, and everything blows up before I even get a
chance to find real errors.
This is a design flaw. If MSVC next version comes out, I should at
least be able to try to build what worked last version.
>>>> Its not like
>>>> everyone submitting to boost doesn't complain about having to learn a
>>>> non-standard build system that isn't documented richly enough to write
>>>> scripts from scratch.
>>> Again, prove it.
>> I've seen a number of emails here where people basically said "and
>> then I had to learn this extra crazy language to get stuff into
>> boost." I'm not sure why this is a contentious point. By definition
>> you have to learn an entire new build system to get something into
>> boost. Is there a simple "and this is what you need to do to build a
>> new module in boost webpage?" No there isn't. There never has been.
> I agree with this. For potential library developers there should have been a
> web page for setting up Boost Build to build, test, and possibly write docs
> for a Boost library. Either that or this "use cases" methodology for library
> developers should have been a prominent part of the Boost Build docs.
>>>> These are not new problems. I am *really* glad
>>>> that SC did something because in my mind it means boost won't die a
>>>> slow death to just posting independent libs on github.
>>> Prove that the build system is the reason Boost is "dying a slow death"?
>>> For that matter prove that Boost is dying in the first place.
>> How many of the latest proposals for C++ have actually been in boost?
>> Ranges? Polymorphic allocators? I can not remember the last time I
>> watched a CPPCON/etc video and someone was talking about bringing
>> something from boost into the standard library besides filesystem
>> (which is legacy) or asio (which technically is standalone).
> How many new libraries do you think that the C++ standards committee ever
> accepts into the C++ standard ? Very, very few out of all the potential
> libraries in Boost or otherwise that might come to their attention. The real
> test is whether C++ developers rely on any of the 130+ libraries under the
> Boost umbrella. I think quite a few still do.
Maybe, but the more non-standardish things that have to be done the
more you put on peoples plates...
(I think its interesting GSL got done under non-boost header too given
that boost seems to be the perfect place to have put/used that).
>>> Note.. Yes I will keep posting in these threads in response to false
>>> accusations to the decades of work some of us have put into Boost.
>> Standing here and shouting at users for for making "false accusations"
>> when they have real, specific issues with boost is not a way to make
>> boost look friendly or the place to contribute to.
> No one is shouting.
It certainly feels like some people are not very friendly on the
issue. I realize that's a feeling, but the mailing list is not
exactly a friendly place sometimes for people who aren't in the
> It is a give-and-take discussion. I for one am satisfied
> that if the Boost Steering Committee want to change to CMake that is fine
> and Boost needs to do so to accommodate C++ developers and end-users who are
> more used to CMake and its ways of doing things.
>>> -- Rene Rivera
>>> -- Grafik - Don't Assume Anything
>>> -- Robot Dreams - http://robot-dreams.net
>>> -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk