Re: [boost] Where we are 1.65.0

Subject: Re: [boost] Where we are 1.65.0
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2017-08-09 20:56:50

Le 09.08.17 à 20:20, Stephan T. Lavavej via Boost a écrit :
> [Marshall Clow]
>> * Some libraries didn't build with ToT clang/libc++  (Locale, Wave and Test)
>> This is because in C++17, some deprecated library features have been removed.
>> [bind1st, mem_fun, auto_ptr, random_shuffle, etc ]
>> Boost.Config has support for these removals, but this was ... incomplete.
>> [ This is on me; I did the partial job of adding these to Config's libc++ support a while back ]
>> Normally, I would be tempted to say "Well, clang 5 is not shipping yet, and so we can put
>> this off until 1.66.0". But both clang 5 and C++17 are imminent (they will both happen well
>> before the 1.66 release, and so I think we should fix this now.

Thanks for the feedback! and thanks again for the boost.test fixes!

>> Also, a future version of MSVC will have the same library issues.
>
> This was actually implemented in MSVC 2015 RTM, as opt-in behavior. In MSVC 2015.3 when /std:c++latest was added, we made C++17 mode remove auto_ptr/etc. by default (with the same macro being used for opt-out).
>
> I would like to gently point out that I gave Boost a heads-up when all of this happened, in classic emails like "Removing auto_ptr/etc. from Boost" on March 18, 2015 and "Boost and auto_ptr (was Boost 1.60.0 beta 1...)" on November 11, 2015.
>
> We're treating the other C++17 removals identically. The old iostreams members are hopefully totally irrelevant, the std::function allocator support probably is too (I would expect boost::function to be used), but std::unexpected() removal may be relevant. That one's going to be enabled by /std:c++17 and /std:c++latest in 2017's second toolset update.
>
> As a reminder, "std::auto_ptr in public interfaces" on May 20, 2017 is repeating this cycle, with early notification of deprecation warnings:
>
> [STL]
>> Additionally, in VC 2017's second toolset update (not the first one that's being released soon),
>> I am planning to aggressively warn about C++17's deprecated features in C++17 mode (/std:c++17
>> or /std:c++latest). All of the library stuff in Annex D will emit warnings, except for the <meow.h>
>> C headers (it's silly that they're deprecated). [snipped outdated sentence] This is going to be
>> pretty noisy, but it'll ultimately make migrating code to C++20 and beyond easier.
>
>> I plan to have a system of fine-grained escape hatch macros, and a big "silence all C++17 deprecation
>> warnings" macro, but libraries like Boost will need to avoid the deprecated components (or locally
>> suppress C4996) since they don't really control the user's preferences.
>
>> Auditing Boost right now for unnecessary use of the Annex D stuff would be a good idea.
>> Stuff like std::iterator, the old allocator members, and std::result_of are probably commonly used.
>
> Thanks,
> STL

You're right!

We definitely need runners for this, and the plethora of 
architectures/compilers is well covered for established compilers, not 
so well maybe for new compilers.

I do not know about the state of VS2017 /std:c++17, I believe teeks99-09 
is doing it:
http://www.boost.org/development/tests/develop/teeks99-09-p-win2012R2-64on64.html 

Also, if I recall, the build was also having trouble for support of 
VS2017, which ate up some resources.

OTOH,

* as a developer, I would say: bad luck, give me runners, and I will fix 
the problems as I see them coming
* as a user, I would say: boost is so-so ahead of its time for C++ (and 
many more bad things of course)

that makes me feel like:
* having support for "cutting edge" sounds to me better than "release 
often", especially when the price is so low (most of the problems seems 
to be fixed, we need to cycle the runners)
* fixing things in RCs, like now, is exactly the right time
* and fixing means also having runners for those compilers, so that the 
development can go smoothly for next release. Having to wait half a 
release cycle is too short for developments to my opinion.

I am all in favor of postponing the release and getting those fixed.

I am also wondering about several topics that are orthogonal to 
developments:
* would a different branching policy help here? it has been mentioned 
that some PRs are on the pipe, but those need to stage to develop and 
then merged to master, which ultimately will pull some unwanted changes 
that are not addressing the issues specific to the release
* would it make sense to share the know-how on how to set up a new 
compiler? I am not referring to how to run the regression script, but 
rather on how to install a test machine with a cutting edge compiler. 
This is more an IT perspective, but maybe gathering that knowledge would 
help us having more test machines?

Thanks,
Raffi