Re: [boost] Let's stop distributing binaries

Subject: Re: [boost] Let's stop distributing binaries
From: Olaf van der Spek (ml_at_[hidden])
Date: 2018-08-30 06:16:21

On Wed, Aug 29, 2018 at 10:37 PM, Robert Ramey via Boost
<boost_at_[hidden]> wrote:
> On 8/29/18 10:02 AM, Olaf van der Spek via Boost wrote:
>>
>> On Wed, Aug 29, 2018 at 6:35 PM, Robert Ramey via Boost
>> <boost_at_[hidden]> wrote:
>>>
>>> a) since the user would be compiling everything with his own favorite
>>> compiler
>>
>>
>> Not if he's using package management (Linux, vcpkg @ Windows).
>
>
> Hmmm - I don't really know what vcpkg actually does.  Basically if we
> distribute only source and no binary then we're not responsible for all the
> stupid stuff that people do with it.

Moving problems doesn't solve them. ;)

>>
>>> with the -std setting he desires,
>>
>>
>> Are you sure about that?
>> Even if he has projects with different -std settings?
>
>
> LOL - if he has projects with different -std settings - e.g. a dll and an
> application which calls the dll, he has problems that we can't solve.

I mean one C++20 app and one C++11 app, both using Boost. He'd have to
build Boost multiple times for different std levels. When the std
level gets encoded into the binary names this'll be simpler.

>>> b) LOL - It's been stated numerous times that the the Boost policy is
>>> that a
>>> library must only be compatible with the currently release C++ standard.
>>
>>
>> Apparently that's not documented properly. Where is it documented anyway?
>
>
> I don't know. I'm sure it's documented somewhere.  There are several well
> known library which illustrate its veracity. And it's stated on this list
> about every 6 months or so. It's been stated several times in this thread.
> Regardless of where it's documented, or even if its not, it happens to be
> true.

Sure, but if it's not documented it'll keep coming up for discussion.

>> And where's the list of supported compilers listed?
>
>
> That would depend on the particular library.  All boost library are supposed

I'd swear there used to be a list of tested compilers somewhere on the website.

> to work with the current standard (at least when approved).  So any compiler
> which implements the current standard should be guaranteed to be able to
> build and use the library.  Of course this is complicated by the fact that
> there is no C++ compiler and standard library which actually correctly
> implements the standard.  This in turn is complicated by the fact that there
> is no universal agreement on what the standard actually means in many
> places.  This in turn is complicated by the fact it is very popular to add
> features (initialization) that no one can really figure them out.
>
> Alas - I'm off topic.
>
>> Are you sure 'we' are not expecting libs to work with non-C++17 compilers?
>
>
> Hmmm I don't know that I can speak for "we".  But I expect that a Boost
> library will work with any compiler conforming the the standard existing at
> the time the library was approved.  Since C++ strives to maintain backward

Fair enough, but that doesn't tell a user whether a lib that's
approved in 2018 works on a certain compilers that supports C++14 but
not C++17.

> compatibility, I expect that that library will be compatible with all
> subsequent C++ compilers.  Of course this is not strictly true.  Any boost
> library using std::auto had to be tweaked when auto was dropped.  But in
> practice it's true enough for government work.

-- 
Olaf