Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-07-27 16:30:24

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

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

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.

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

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

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

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