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 20:05:02

On 7/27/2017 2:42 PM, Gary Furnish via Boost wrote:
> On Thu, Jul 27, 2017 at 10:30 AM, Edward Diener via Boost
> <boost_at_[hidden]> wrote:
>> 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.
>>
> 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.

It is very hard to adopt a new build system when you get used to the one 
that exists. It is much like switching from programming from one 
computer language to another one. People are passionate and tempers 
often get high.

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

The solution is always to raise issues and if there is no response than 
you have a right to be ticked off. I do agree with you that for many, if 
not most, programmers Boost Build is arcane. But it actually works with 
much less amount of scripting work required than CMake does. Nonetheless 
I agree with the move to CMake, as much as I hope Boost Build still 
remains as an alternative for end-users who also like using it.

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

Tutorials may not be for everyone as a way of understanding the basic 
CMake concepts and how they relate to each other. I specifically have to 
understand concepts and their relationship before I even want to look at 
tutorials. I will almost certainly end up buying the CMake book in order 
to understand it.

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

You should report these problems with [config] starting your subject as 
this as feature detection is the essence of the Boost config library.

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

I run local tests of various Boost libraries using VC++8.0 through the 
latest VC++14.1. I have never run into a configuration problem of which 
I am aware as reflected by those tests. If you have problems doing this 
with any Boost library you should report it.