Hi Daniel, Op 14-12-2017 om 16:04 schreef Daniel James via Boost:

On 14 December 2017 at 14:47, Barend Gehrels via Boost wrote:

...

On December 6, following your request, I modified release notes for Geometry and did a "Propose file change" in github. However, those changes are not yet in the release notes. Maybe what I did was not sufficient or I did make another mistake. It looks like you edited the file and created a branch:

https://github.com/barendgehrels/website/tree/patch-2

But after editing the file there's another form to create a pull request. I guess you didn't submit it, or something went wrong when submitting it. Seems like an easy mistake to make, so I'll point it out in the future.

Indeed, I did not do that. Will do next time.

...

Anyway, is it still possible to add them? Sure, I'll merge your branch, which is slightly different.

Thanks! I see it is there now, great. Regards, Barend

On 14 December 2017 at 15:02, Olaf van der Spek wrote:

On Thu, Dec 14, 2017 at 2:03 PM, Daniel James via Boost wrote:

...

The second release candidates for the 1.66.0 release are now available at:

https://dl.bintray.com/boostorg/prerelease/

Repository path missing or not specified.

Sorry, should be: https://dl.bintray.com/boostorg/release/1.66.0/source/

On 12/14/17 19:11, Peter Dimov via Boost wrote:

Olaf van der Spek wrote:

...

"Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an update Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message."

generates so much noise, could it be suppressed for 15.5 if the updates to config can't be included?

I agree that this message isn't going to make us many new friends, and that it doesn't provide much value in this specific case.

Any new version of a compiler can break something that was working before. MSVC has especially bad history. If we haven't tested it with 1.66 then we should say so. Release notes are probably a better place though.

On Fri, Dec 15, 2017 at 11:10 AM, Daniel James via Boost wrote:

On 14 December 2017 at 16:11, Peter Dimov via Boost wrote:

...

Olaf van der Spek wrote:

...

"Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an update Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message."

generates so much noise, could it be suppressed for 15.5 if the updates to config can't be included?

I agree that this message isn't going to make us many new friends, and that it doesn't provide much value in this specific case.

You've both been aware if this message for several weeks, and it comes up every time there's a new Visual C++, so it's a bit awkward to ask for something to be done a few days before the release. A release

I was expecting the updates to config to be included in 1.66.0.

candidate thread is pretty much the worst place to deal with a long standing problem. We don't have testers for the new version of Visual Studio yet, so the warning message is entirely correct. Silencing it would do no favours to anyone who relies on it. I suppose the question is whether anyone really does rely on it, but making a design change at this late stage is probably a bad idea.

If you want to discuss this, I'd suggest starting a new thread, and putting '[config]' in the subject, so that it will get the attention of the appropriate people. Release managers shouldn't force a change on a library that's working as intended, unless it's causing failures.

Will do -- Olaf

On 15 December 2017 at 05:47, John Maddock via Boost wrote:

BTW, changes to config are just the tip of the iceberg: I suspect 15.5 in C++17 /permissive- mode will break quite a few libraries given that things that were in the std have now been removed.

Yip, FWIW, locale doesn't build (RC1) due to the removal of std::auto_ptr().

In short, have a complete Boost release that fully supports 15.5 requires quite a bit of work. In the mean time, I'm sure PR's against effected libraries would be welcome!

And then there is clang/llvm (in combination with the MS-STL)... degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

On Fri, Dec 15, 2017 at 12:47 PM, John Maddock via Boost wrote:

...

I was expecting the updates to config to be included in 1.66.0.

How? Our release process was started before 15.5 was released, and the

A preview of 15.5 was released October 11 @ https://blogs.msdn.microsoft.com/vcblog/2017/10/11/productivity-structure-vi... This was posted to the list a day later.

configuration changes are not especially trivial - and we're still without a volunteer running the regression tests for 15.5 so while I'm reasonably sure

Who runs the tests for other MSVC versions? Was there a call for volunteers? Is there a page that explains this process?

they don't break the libraries that depend on those macros since I tested before and after changes against develop, I confess I'm less sure what happens when we integrate everything to master.

BTW, changes to config are just the tip of the iceberg: I suspect 15.5 in C++17 /permissive- mode will break quite a few libraries given that things that were in the std have now been removed.

Probably, but /permissive- isn't required (yet). That stuff has been deprecated for a while as well, how come action wasn't taken?

In short, have a complete Boost release that fully supports 15.5 requires quite a bit of work. In the mean time, I'm sure PR's against effected libraries would be welcome!

-- Olaf

[John Maddock]

I suspect 15.5 in C++17 /permissive- mode will break quite a few libraries given that things that were in the std have now been removed.

Please note that /std:c++17 and /permissive- are orthogonal. /std:c++17 requests C++17 features, and additionally activates deprecation warnings in the STL and removals in the STL and Core Language. See https://blogs.msdn.microsoft.com/vcblog/2017/12/08/c17-feature-removals-and-... for more info. /permissive- activates our partial implementation of two-phase name lookup, and disables behavior that contradicts the Standard. [Olaf van der Spek]

That stuff has been deprecated for a while as well, how come action wasn't taken?

I've been notifying Boost for years, starting on March 18, 2015 and most recently on August 9, 2017: "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

[Gavin Lambert]

This does not seem like the first time a new MSVC release occurred just days prior to a Boost release, causing consternation amongst people who expected the latter to work with the former.

Or perhaps people should react more pro-actively to the preview releases

Yes, that would be wise.

(a common theme I've heard posted here is to ignore preview releases because things will be different in the final release)?

That is unwise guidance. Here's a general description of how our releases work (no specific promises about the future): * By the time that update N ships (e.g. 15.5), update N + 1 (e.g. 15.6) appears in the preview channel around the same time. * To achieve that, update N + 1 actually branched for release a while ago, and active development (master) is flowing into a later update. * Fixes from master are backported to the Preview branch, but there's a process involving a fair amount of scrutiny and paperwork, ensuring that only important fixes are backported. * While the details vary, new features stop appearing in Previews early on; e.g. it is possible for features to appear between Preview 1 and Preview 2 of an update (as will be the case for 15.6) but later previews are even less likely to contain new features and by the time that several Previews have come out, it is in a highly locked down state and significant changes are unlikely. To summarize: don't ignore Preview releases. Use them for testing. At most you can skip Preview 1 of each update if you like, but don't ignore any others. STL

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Olaf van der Spek via Boost Sent: Donnerstag, 14. Dezember 2017 16:11 To: boost@lists.boost.org Cc: Olaf van der Spek ; boost-users@lists.boost.org Subject: Re: [boost] [release] Boost 1.66.0 Release Candidate 2

On Thu, Dec 14, 2017 at 2:03 PM, Daniel James via Boost wrote:

...

As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

"Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an update Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message." generates so much noise, could it be suppressed for 15.5 if the updates to config can't be included?

The message itself tells a trivial way to suppress it - so I don't see any problem? Marcel

On 12/18/17 00:41, Daniel James via Boost wrote:

On 17 December 2017 at 18:31, Andrey Semashev via Boost wrote:

...

Will there be another RC?

I have been informed of this problem:

https://github.com/boostorg/log/issues/44

which is basically a potential conflict between Boost.Thread and Boost.Log on Windows if headers from both libraries are included. In particular, the problematic header in Boost.Log is boost/log/utility/permissions.hpp, which is only used for IPC-related functionality.

The fix is in develop:

https://github.com/boostorg/log/commit/525c53b1a735f21d9b51d432b93a79f4f8b73...

If there is a chance to include it in 1.66, I would like to do it.

If not, could the link to this commit be added to the release notes?

I wasn't planning on another release candidate, but if including the headers from two libraries causes a compile failure, that seems pretty serious.

It's not *any* headers but rather permissions.hpp from Boost.Log and some headers from Boost.Thread (I'm not sure which as there are multiple headers in Boost.Thread that could make use of Boost.WinAPI, which could cause the conflict). I don't think other libraries using Boost.WinAPI are affected because, unlike Boost.Thread, they have their own namespaces. Also, IPC is not the core functionality of Boost.Log, so the library is not completely useless without it, but surely its users can be affected. In any case, I'm planning to merge the fix to master tomorrow, although it won't make it into the release per se. The commit should apply cleanly over the current master (i.e. it can be cherry-picked to release). Please, let me know if you think it's not important enough to delay the release so that I can prepare a PR for the release notes.

On 12/18/17 04:00, Daniel James wrote:

On 17 December 2017 at 23:26, Andrey Semashev via Boost wrote:

...

It's not *any* headers but rather permissions.hpp from Boost.Log and some headers from Boost.Thread (I'm not sure which as there are multiple headers in Boost.Thread that could make use of Boost.WinAPI, which could cause the conflict). I don't think other libraries using Boost.WinAPI are affected because, unlike Boost.Thread, they have their own namespaces. Also, IPC is not the core functionality of Boost.Log, so the library is not completely useless without it, but surely its users can be affected.

In any case, I'm planning to merge the fix to master tomorrow, although it won't make it into the release per se. The commit should apply cleanly over the current master (i.e. it can be cherry-picked to release). Please, let me know if you think it's not important enough to delay the release so that I can prepare a PR for the release notes.

OK then, I'll go ahead with the release tomorrow, and we can add a link to a patch.

Luckily, Vicente didn't merge the update to Boost.Thread to use the new location and namespace of Boost.WinAPI to master, so this conflict doesn't appear. I was wondering why the test matrix for Boost.Log master was not showing the problems and apparently this is the reason. Sorry I didn't realize this earlier. So, to summarise: - the problem was found and fixed in develop - it didn't appear in master and should not affect the release because Boost.Thread was not merged - I have now merged Boost.Log to master, so even if Boost.Thread is merged, it should still be fine Sorry for the noise.

On 12/18/17 16:35, Daniel James via Boost wrote:

On 18 December 2017 at 12:54, Andrey Semashev via Boost wrote:

...

So, to summarise:

- the problem was found and fixed in develop - it didn't appear in master and should not affect the release because Boost.Thread was not merged - I have now merged Boost.Log to master, so even if Boost.Thread is merged, it should still be fine

Just to be clear, as I think I need to fully understand this. The problem in issue #44 is that a lookup for 'winapi' from inside 'boost::detail' picks up the 'boost::detail::winapi' namespace from your log header, but without including the header that sets up the 'boost::detail::winapi' namespace to import all of 'boost::winapi'.

Correct. The updated Boost.Thread includes the new Boost.WinAPI headers which define its symbols in `boost::winapi`, so Boost.Thread expects `winapi` to resolve to `boost::winapi`.

The master branch of Boost.Thread does include the header, so there's no problem there. And this can only happen inside 'boost::detail', so it shouldn't ever affect user code.

Also correct. And user's code should not use Boost.WinAPI in the first place.

Le 17/12/2017 à 22:41, Daniel James via Boost a écrit :

...

Will there be another RC?

I have been informed of this problem:

https://github.com/boostorg/log/issues/44

which is basically a potential conflict between Boost.Thread and Boost.Log on Windows if headers from both libraries are included. In particular, the problematic header in Boost.Log is boost/log/utility/permissions.hpp, which is only used for IPC-related functionality.

The fix is in develop:

https://github.com/boostorg/log/commit/525c53b1a735f21d9b51d432b93a79f4f8b73...

If there is a chance to include it in 1.66, I would like to do it.

If not, could the link to this commit be added to the release notes? I wasn't planning on another release candidate, but if including the

On 17 December 2017 at 18:31, Andrey Semashev via Boost wrote: headers from two libraries causes a compile failure, that seems pretty serious.

Please, let me now if I should merge them. Vicente