[release] Boost 1.66.0 Release Candidate 2
The second release candidates for the 1.66.0 release are now available at: <https://dl.bintray.com/boostorg/prerelease/> The in progress release notes are: <http://www.boost.org/users/history/in_progress.html> Library documentation is available at: <http://www.boost.org/doc/libs/1_66_0/> The SHA256 checksums are as follows: 596389389c005814ecb2a6b64c31dccd2c3e6fbc5a802b4dfada999ae5844628 boost_1_66_0_rc2.7z 5721818253e6a0989583192f96782c4a98eb6204965316df9f5ad75819225ca9 boost_1_66_0_rc2.tar.bz2 bd0df411efd9a585e5a2212275f8762079fed8842264954675a4fddc46cfcf60 boost_1_66_0_rc2.tar.gz e1c55ebb00886c1a96528e4024be98a38b815115f62ecfe878fcf587ba715aad boost_1_66_0_rc2.zip 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.
Hi Daniel, Op 14-12-2017 om 14:03 schreef Daniel James via Boost:
The second release candidates for the 1.66.0 release are now available at:
<https://dl.bintray.com/boostorg/prerelease/>
The in progress release notes are:
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. Anyway, is it still possible to add them? These are the changes: updated libraries: added Geometry * [phrase library..[@/libs/geometry/ Geometry]:] * Add distance for geographic PointLike/AnyGeometry. * Fixes in validity of union/intersection/difference/buffer * Fixes in results of union/intersection/difference which could be incorrect in some complex cases * Fixes in set and relational operations for non-cartesian coordinate systems. Thanks, regards, Barend
On 14 December 2017 at 14:47, Barend Gehrels via Boost <boost@lists.boost.org> 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.
Anyway, is it still possible to add them?
Sure, I'll merge your branch, which is slightly different.
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 <boost@lists.boost.org> 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 Thu, Dec 14, 2017 at 2:03 PM, Daniel James via Boost <boost@lists.boost.org> wrote:
The second release candidates for the 1.66.0 release are now available at:
Repository path missing or not specified.
On 14 December 2017 at 15:02, Olaf van der Spek <ml@vdspek.org> wrote:
On Thu, Dec 14, 2017 at 2:03 PM, Daniel James via Boost <boost@lists.boost.org> wrote:
The second release candidates for the 1.66.0 release are now available at:
Repository path missing or not specified.
Sorry, should be: https://dl.bintray.com/boostorg/release/1.66.0/source/
Hi,
-----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:02 To: boost@lists.boost.org Cc: Olaf van der Spek <ml@vdspek.org>; 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 <boost@lists.boost.org> wrote:
The second release candidates for the 1.66.0 release are now available at:
Repository path missing or not specified.
the correct path seems to be https://dl.bintray.com/boostorg/release/1.66.0/source/ Marcel
On Thu, Dec 14, 2017 at 2:03 PM, Daniel James via Boost <boost@lists.boost.org> 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? -- Olaf
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.
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 14 December 2017 at 16:11, Peter Dimov via Boost <boost@lists.boost.org> 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 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.
On Fri, Dec 15, 2017 at 11:10 AM, Daniel James via Boost <boost@lists.boost.org> wrote:
On 14 December 2017 at 16:11, Peter Dimov via Boost <boost@lists.boost.org> 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
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 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 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. 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! John. --- This email has been checked for viruses by AVG. http://www.avg.com
On 15 December 2017 at 05:47, John Maddock via Boost <boost@lists.boost.org> 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 15 December 2017 at 12:22, degski via Boost <boost@lists.boost.org> wrote:
Yip, FWIW, locale doesn't build (RC1) due to the removal of std::auto_ptr().
It looks like that was fixed in develop, but never merged to master. It's too late to include it, but I could add a patch to the release notes.
On Fri, Dec 15, 2017 at 12:47 PM, John Maddock via Boost <boost@lists.boost.org> 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
On 12/15/2017 7:33 AM, Olaf van der Spek via Boost wrote:
On Fri, Dec 15, 2017 at 12:47 PM, John Maddock via Boost <boost@lists.boost.org> 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?
Action was taken for quite a few libraries but it is up to the library maintainers of each library, and not all maintainers implemented the necessary changes for C++17 and what was removed. PRs are always welcome.
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!
[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
On 16/12/2017 00:47, John Maddock 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 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 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.
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. Perhaps the release schedules are too similar, and Boost should apply a permanent calendar offset to give more time to react? Or perhaps people should react more pro-actively to the preview releases (a common theme I've heard posted here is to ignore preview releases because things will be different in the final release)?
[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
Daniel James wrote:
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. ...
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.
Nobody relies on it, and it's not actionable. The only thing you can possibly do is silence it, and the only thing you would do is silence it. Note that this is not a general statement. It's about this specific case.
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.
The appropriate people have already applied the necessary changes to Config, and those changes are (correctly) not going into the release. There's nothing the appropriate people need to do.
Release managers shouldn't force a change on a library that's working as intended, unless it's causing failures.
Your call.
-----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 <ml@vdspek.org>; 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 <boost@lists.boost.org> 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 Fri, Dec 15, 2017 at 11:22 AM, Marcel Raad <Marcel.Raad@teamviewer.com> wrote:
-----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 <ml@vdspek.org>; 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 <boost@lists.boost.org> 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?
Documentation is not a solution. ;) And looking for an updateD Boost version returns 404. On one hand it's a non-issue, on the other it's an issue that shouldn't have been there. One could define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE but then project files have to be updated.. and after some time you have to remember to remove the define again. -- Olaf
On 12/14/17 16:03, 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/>
The in progress release notes are:
<http://www.boost.org/users/history/in_progress.html>
Library documentation is available at:
<http://www.boost.org/doc/libs/1_66_0/>
The SHA256 checksums are as follows:
596389389c005814ecb2a6b64c31dccd2c3e6fbc5a802b4dfada999ae5844628 boost_1_66_0_rc2.7z 5721818253e6a0989583192f96782c4a98eb6204965316df9f5ad75819225ca9 boost_1_66_0_rc2.tar.bz2 bd0df411efd9a585e5a2212275f8762079fed8842264954675a4fddc46cfcf60 boost_1_66_0_rc2.tar.gz e1c55ebb00886c1a96528e4024be98a38b815115f62ecfe878fcf587ba715aad boost_1_66_0_rc2.zip
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.
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? Thanks.
On 17 December 2017 at 18:31, Andrey Semashev via Boost <boost@lists.boost.org> 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.
On 12/18/17 00:41, Daniel James via Boost wrote:
On 17 December 2017 at 18:31, Andrey Semashev via Boost <boost@lists.boost.org> 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 17 December 2017 at 23:26, Andrey Semashev via Boost <boost@lists.boost.org> 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.
On 12/18/17 04:00, Daniel James wrote:
On 17 December 2017 at 23:26, Andrey Semashev via Boost <boost@lists.boost.org> 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 18 December 2017 at 12:54, Andrey Semashev via Boost <boost@lists.boost.org> 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'. 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.
On 12/18/17 16:35, Daniel James via Boost wrote:
On 18 December 2017 at 12:54, Andrey Semashev via Boost <boost@lists.boost.org> 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.
On 18 December 2017 at 13:59, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
On 12/18/17 16:35, Daniel James via Boost wrote:
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.
OK thanks. I'm going to go ahead with the release now. Does seem like a good demonstration of why namespaces should always be fully qualified.
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 <boost@lists.boost.org> wrote: headers from two libraries causes a compile failure, that seems pretty serious.
Please, let me now if I should merge them. Vicente
participants (12)
-
Andrey Semashev -
Barend Gehrels -
Daniel James -
degski -
Edward Diener -
Gavin Lambert -
John Maddock -
Marcel Raad -
Olaf van der Spek -
Peter Dimov -
Stephan T. Lavavej -
Vicente J. Botet Escriba