On 11/11/17 01:49, James E. King, III via Boost wrote:

On Fri, Nov 10, 2017 at 9:20 AM, Daniel James via Boost < boost@lists.boost.org> wrote:

...

Hi,

I'll close the master branch for the beta release tomorrow. Sorry we've been quiet about the release and that this is a bit short notice.

I had a late request to revert the change to the boost:uuids::string_generator invalid parsing exception type (was std::runtime_error, I had changed it to std::invalid_argument; the request was to change it back). I need to make this change and remove the relevant release note.

Some relevant links. The original (incorrect) change was: https://github.com/boostorg/uuid/commit/07f68d3b9ce95bbde19b0212293f5110d363... The change that is proposed to be merged is this: https://github.com/boostorg/uuid/pull/54

Do I have time to do this?

(Disclaimer: I'm not a release manager.) Normally, you need some time for tests to cycle (in our official testers). The change is rather simple though, it might be fine to just wait for CI to complete, which it hopefully will until the beta freeze. In any case, there will be a window open for merging after the beta is out. You can merge the fix then.

On 10.11.2017 19:17, Daniel James via Boost wrote:

On 10 November 2017 at 23:24, Andrey Semashev via Boost <boost@lists.boost.org> wrote:

...

Some relevant links. The original (incorrect) change was:

https://github.com/boostorg/uuid/commit/07f68d3b9ce95bbde19b0212293f5110d363...

The change that is proposed to be merged is this:

https://github.com/boostorg/uuid/pull/54 Thanks, that's helpful. This should certainly be included in the final release, but I think it can wait until after the beta.

I also haven't got a chance to merge Boost.Python patches from develop to master, as I totally missed the fact that we are approaching beta. Any suggestions what I should do ? Merge now ? After the beta ? Not at all ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

On Fri, Nov 10, 2017 at 7:17 PM, Daniel James via Boost < boost@lists.boost.org> wrote:

On 10 November 2017 at 23:24, Andrey Semashev via Boost <boost@lists.boost.org> wrote:

...

Some relevant links. The original (incorrect) change was:

https://github.com/boostorg/uuid/commit/07f68d3b9ce95bbde19b0212293f51

10d363e050

...

The change that is proposed to be merged is this:

https://github.com/boostorg/uuid/pull/54

Thanks, that's helpful. This should certainly be included in the final release, but I think it can wait until after the beta.

My PR build of this revert failed in serialization, something must have just changed in serialization. .\boost/serialization/singleton.hpp(155) : error C2491: 'boost::serialization::singleton<T>::m_instance' : definition of dllimport static data member not allowed <https://ci.appveyor.com/project/jeking3/uuid-gaamf/build/1.0.76-develop/job/w2ye903t9e8yc7hu#L3283> with <https://ci.appveyor.com/project/jeking3/uuid-gaamf/build/1.0.76-develop/job/w2ye903t9e8yc7hu#L3284> [ <https://ci.appveyor.com/project/jeking3/uuid-gaamf/build/1.0.76-develop/job/w2ye903t9e8yc7hu#L3285> T=boost::archive::detail::extra_detail::map<boost::archive::binary_iarchive> <https://ci.appveyor.com/project/jeking3/uuid-gaamf/build/1.0.76-develop/job/w2ye903t9e8yc7hu#L3286> ] <https://ci.appveyor.com/project/jeking3/uuid-gaamf/build/1.0.76-develop/job/w2ye903t9e8yc7hu#L3287> <https://ci.appveyor.com/project/jeking3/uuid-gaamf/build/1.0.76-develop/job/w2ye903t9e8yc7hu#L3288> call "C:\Users\appveyor\AppData\Local\Temp\1\b2_msvc_10.0_vcvarsall_x86.cmd" >nul <https://ci.appveyor.com/project/jeking3/uuid-gaamf/build/1.0.76-develop/job/w2ye903t9e8yc7hu#L3289>cl /Zm800

On 11/10/17 6:46 PM, Daniel James via Boost wrote:

On 11 November 2017 at 00:56, James E. King, III via Boost <boost@lists.boost.org> wrote:

...

...

My PR build of this revert failed in serialization, something must have just changed in serialization.

Thanks for catching that, hopefully serialization is better in master? I've got to go to bed now, so I'll look into what's going on with serialization in the morning.

I'm working on this now. Hopefully it will be resolved soon. Robert Ramey

On 11/11/17 12:53 AM, Daniel James via Boost wrote:

On 11 November 2017 at 04:44, Robert Ramey via Boost <boost@lists.boost.org> wrote:

...

I'm working on this now. Hopefully it will be resolved soon.

Thanks. Does this also affect master? My main concern right now is when we can go ahead with the beta.

The master should be OK. I merged in a previous batch of changes which were extensively tested before embarking on this round. I'm still hoping I can get this last relatively small set in under the wire. But it will be inconvenient if I can't do this, but it won't be a disaster. Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Sat, Nov 11, 2017 at 12:49 PM, Daniel James via Boost < boost@lists.boost.org> wrote:

On 11 November 2017 at 17:40, Robert Ramey via Boost <boost@lists.boost.org> wrote:

...

On 11/11/17 12:53 AM, Daniel James via Boost wrote:

...

On 11 November 2017 at 04:44, Robert Ramey via Boost <boost@lists.boost.org> wrote:

...

I'm working on this now. Hopefully it will be resolved soon.

Thanks. Does this also affect master? My main concern right now is when we can go ahead with the beta.

The master should be OK. I merged in a previous batch of changes which were extensively tested before embarking on this round.

I'm still hoping I can get this last relatively small set in under the wire. But it will be inconvenient if I can't do this, but it won't be a disaster.

OK, I'll leave master open for serialization and UUID. Please let me know how long you'll need soonish.

uuid is all set on master, I took care of the issues folks wanted changed before the release. Thanks, Jim

On Sat, Nov 11, 2017 at 7:58 AM, Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:

Le 10.11.17 à 15:20, Daniel James via Boost a écrit :

...

Hi,

I'll close the master branch for the beta release tomorrow. Sorry we've been quiet about the release and that this is a bit short notice.

If you haven't written your release notes yet, you can add them to:

https://github.com/boostorg/website/blob/master/feed/history /boost_1_66_0.qbk

Use the pencil icon at the top right of the code to edit it, or you can mail your notes to me, and I'll add them.

thanks,

There is a regression on boost.test on Windows while the code did not change, due to the fact that b2 now have longer paths:

This is what I have for last develop: ..\..\..\bin.v2\libs\test\test\user-defined-types-logging- customization-points.test\msvc-9\debug\threadapi-win32\ threading-multi\writing-test-ts\user-defined-types-logging- customization-points.obj.rsp

This is what I have for new feature branches: ..\..\..\bin.v2\libs\test\test\user-defined-types-logging- customization-points.test\msvc-9\debug\threading-multi\ writing-test-ts\user-defined-types-logging-customization-points.obj

(threadapi-win32 has been added)

The error says " failed to write output file '..\..\..\bin.v2\libs\test\tes t\user-defined-types-logging-customization-points.test\ msvc-9\debug\threadapi-win32\threading-multi\writing-test- ts\user-defined-types-logging-customization-points.obj.rsp'! "

The base folder of my CI is D:\bamboo_build_dir\SW-BCB125-VC2008WIN, and the builds that fail are VS2008, VS2013, VS2015, VS2017.

Would it be possible to revert this change, such that I can use my CI and focus on the code?

You mean revert a series of changes to, IIRC, 4 repos and the superproject? ... Not likely. But you can use either "--abbreviate-paths" or "--hash" option to get shorter paths. < http://www.boost.org/build/doc/html/bbv2/overview/invocation.html#bbv2.overv...

HTH. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

James E. King, III wrote:

Perhaps --abbreviate-paths should be the default behavior for bjam on Windows now, given the default options have broken more than one environment (this is not the first email with this subject in the last month).

Or we could make it check whether the path exceeds PATH_MAX and automatically abbreviate or hash it. Here for instance: https://github.com/boostorg/build/blob/develop/src/build/property-set.jam#L5... we could make hash-maybe hash if the length of $(path) exceeds PATH_MAX.

Rene Rivera wrote:

Problem is that the path max depends on context. For some contexts it's the short 256, or is it 6xx, and some others it's 2K, and yet others it's 32K, and depending on the OS version and some magic registry settings it could be unlimited.

Not really. It's always 260, including the terminating NULL. The limitation will be going away in a decade or two though.

Le 11.11.17 à 15:26, Rene Rivera via Boost a écrit :

On Sat, Nov 11, 2017 at 7:58 AM, Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:

...

Le 10.11.17 à 15:20, Daniel James via Boost a écrit :

...

Hi,

I'll close the master branch for the beta release tomorrow. Sorry we've been quiet about the release and that this is a bit short notice.

If you haven't written your release notes yet, you can add them to:

https://github.com/boostorg/website/blob/master/feed/history /boost_1_66_0.qbk

Use the pencil icon at the top right of the code to edit it, or you can mail your notes to me, and I'll add them.

thanks,

There is a regression on boost.test on Windows while the code did not change, due to the fact that b2 now have longer paths:

This is what I have for last develop: ..\..\..\bin.v2\libs\test\test\user-defined-types-logging- customization-points.test\msvc-9\debug\threadapi-win32\ threading-multi\writing-test-ts\user-defined-types-logging- customization-points.obj.rsp

This is what I have for new feature branches: ..\..\..\bin.v2\libs\test\test\user-defined-types-logging- customization-points.test\msvc-9\debug\threading-multi\ writing-test-ts\user-defined-types-logging-customization-points.obj

(threadapi-win32 has been added)

The error says " failed to write output file '..\..\..\bin.v2\libs\test\tes t\user-defined-types-logging-customization-points.test\ msvc-9\debug\threadapi-win32\threading-multi\writing-test- ts\user-defined-types-logging-customization-points.obj.rsp'! "

The base folder of my CI is D:\bamboo_build_dir\SW-BCB125-VC2008WIN, and the builds that fail are VS2008, VS2013, VS2015, VS2017.

Would it be possible to revert this change, such that I can use my CI and focus on the code?

You mean revert a series of changes to, IIRC, 4 repos and the superproject? ... Not likely. But you can use either "--abbreviate-paths" or "--hash" option to get shorter paths. < http://www.boost.org/build/doc/html/bbv2/overview/invocation.html#bbv2.overv...

...

HTH.

No, I did not mean reverting a series of changes and asking for a lot of work for many people. Thanks for the hint, the "--abbreviate-paths" works perfectly for me! I agree with James E. King, III that it would be good to have it as the default on win32, but if this complicated path scheme is there, there should also be a reason... Thanks again for the quick answer, Raffi

On Sat, Nov 11, 2017 at 11:25 AM, Daniel James via Boost < boost@lists.boost.org> wrote:

On 11 November 2017 at 17:18, Raffi Enficiaud via Boost <boost@lists.boost.org> wrote:

...

No, I did not mean reverting a series of changes and asking for a lot of work for many people. Thanks for the hint, the "--abbreviate-paths" works perfectly for me!

Am I right to assume that this doesn't need to be fixed in the beta?

I believe you are correct. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

AMDG On 11/11/2017 10:18 AM, Raffi Enficiaud via Boost wrote:

No, I did not mean reverting a series of changes and asking for a lot of work for many people. Thanks for the hint, the "--abbreviate-paths" works perfectly for me!

I agree with James E. King, III that it would be good to have it as the default on win32, but if this complicated path scheme is there, there should also be a reason...

Didn't we run into this exact same problem before with address-model/architecture? Ah, here's the code that hides the autodetected value of the feature: https://github.com/boostorg/boost/blob/master/boostcpp.jam#L647 Perhaps we should do the same for threadapi? In Christ, Steven Watanabe

Raffi Enficiaud wrote:

...

The error says " failed to write output file '..\..\..\bin.v2\libs\test\test\user-defined-types-logging-customization-points.test\msvc-9\debug\threadapi-win32\threading-multi\writing-test-ts\user-defined-types-logging-customization-points.obj.rsp'! "

The base folder of my CI is D:\bamboo_build_dir\SW-BCB125-VC2008WIN, and the builds that fail are VS2008, VS2013, VS2015, VS2017.

I was trying to reproduce this but couldn't, it worked for me.

Never mind, I got it to fail. The problem is that the relative path above, which is 200 characters, is combined with the path against which it's relative, in this case D:\bamboo_build_dir\SW-BCB125-VC2008WIN\boost\libs\test\test\ (61 characters), and the Windows limit is 259 characters. My idea was to automatically use --hash on long paths, but it doesn't seem that it would solve much, at least in this specific case. --hash only applies to the property portion of the path: msvc-9\debug\threadapi-win32\threading-multi so even with it applied, you end up with something like ..\..\..\bin.v2\libs\test\test\user-defined-types-logging-customization-points.test\a3248436d9896874e11a11c8feb7f858\writing-test-ts\user-defined-types-logging-customization-points.obj.rsp which isn't that far from the limit itself, as much of the length comes not from the property list. Bottom line, either use a shorter BOOST_ROOT, or shorter test names. :-)

Bottom line, either use a shorter BOOST_ROOT, or shorter test names. :-)

... or `b2 libs/test/test` from the root.