Re: [boost] CMake Announcement from Boost Steering Committee

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
<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.
>>  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.
>>>
>>>
>>>> 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.
>
>>  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.
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
core-dev crowd.
> 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:
> http://lists.boost.org/mailman/listinfo.cgi/boost