Re: [boost] Let's stop distributing binaries

On Wed, Aug 29, 2018 at 10:37 PM, Robert Ramey via Boost 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 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