[release] Boost 1.70.0 Beta 1 is now available

newer
Re: [boost] Master branch open for...

older
[Process] Proposed solution for...

Marshall Clow

13 Mar 2019 13 Mar '19

2:49 p.m.

[ resending with a non-empty subject line ] Boost release 1.70.0 beta 1 is now available at: https://dl.bintray.com/boostorg/beta/1.70.0.beta1/source/ The SHA256 checksums are as follows: dbf89645e509acb2e53eac3c633834f1dec80bd8622e6e652a9741dcf0807f17 ./boost_1_70_0_b1.7z 957b984b58656a3ec00661ecad7ef82e3a094bad36e37b9e6624843237854679 ./boost_1_70_0_b1.tar.bz2 76d149c1fb9e8a5ceb3bc1e5587edc40fa79a43e8b990d877c2210f0382b9421 ./boost_1_70_0_b1.tar.gz 71e990b2c26880521fd98459b184ee172ce1c46dcf554b6eaab7776b8b6369a6 ./boost_1_70_0_b1.zip For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

Show replies by date

Rainer Deyke

19 Mar 19 Mar

9:43 a.m.

On 13.03.19 15:49, Marshall Clow via Boost wrote:

...

For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>.

Please download the beta, give it a try, and report any problems you encounter.

I want to report a problem. Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes instead of on line 32 of boost/test/utils/timer.hpp. -- Rainer Deyke (rainerd@eldwood.com)

degski

11:40 a.m.

On Tue, 19 Mar 2019 at 11:44, Rainer Deyke via Boost wrote:

...

Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes instead of

The correct header should be/is 'Windows.h', it's capitalized, MinGW has a similar problem, IIRC. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*

Rainer Deyke

3:08 p.m.

On 19.03.19 12:40, degski via Boost wrote:

...

On Tue, 19 Mar 2019 at 11:44, Rainer Deyke via Boost wrote:

...
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes instead of

The correct header should be/is 'Windows.h', it's capitalized, MinGW has a similar problem, IIRC.

It's not capitalized in the 30 instances of '#include ' in Boost header files, including 3 from Boost.Test, and it's not capitalized on my file system. It's also not capitalized on the Wikipedia page, it's not /consistently/ capitalized by Microsoft themselves, and even Microsoft are switching to lower case where portability matters: see https://github.com/Microsoft/WinObjC/commit/9e55e2a7cb67fe9a4b3fffb491f7eb62.... -- Rainer Deyke (rainerd@eldwood.com)

Raffi Enficiaud

22 Mar 22 Mar

12:13 a.m.

On 19.03.19 16:08, Rainer Deyke via Boost wrote:

...

On 19.03.19 12:40, degski via Boost wrote:

...
On Tue, 19 Mar 2019 at 11:44, Rainer Deyke via Boost wrote:

...
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes instead of

The correct header should be/is 'Windows.h', it's capitalized, MinGW has a similar problem, IIRC.

It's not capitalized in the 30 instances of '#include ' in Boost header files, including 3 from Boost.Test, and it's not capitalized on my file system. It's also not capitalized on the Wikipedia page, it's not /consistently/ capitalized by Microsoft themselves, and even Microsoft are switching to lower case where portability matters: see https://github.com/Microsoft/WinObjC/commit/9e55e2a7cb67fe9a4b3fffb491f7eb62....

I just took the way it appears in the documentation: https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-cr... Windows file system does not care whether it is capitalized or not, and MinGW should not be sensitive to that. I've seen only this header with an upper case W so far, this is typically a Linux issue. Raffi

degski

5:32 a.m.

On Fri, 22 Mar 2019 at 02:13, Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:

...

On 19.03.19 16:08, Rainer Deyke via Boost wrote:

...
On 19.03.19 12:40, degski via Boost wrote:

...
On Tue, 19 Mar 2019 at 11:44, Rainer Deyke via Boost wrote:

...
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes instead of

The correct header should be/is 'Windows.h', it's capitalized, MinGW has a similar problem, IIRC.

It's not capitalized in the 30 instances of '#include ' in Boost header files, including 3 from Boost.Test, and it's not capitalized on my file system. It's also not capitalized on the Wikipedia page, it's not /consistently/ capitalized by Microsoft themselves, and even Microsoft are switching to lower case where portability matters: see

https://github.com/Microsoft/WinObjC/commit/9e55e2a7cb67fe9a4b3fffb491f7eb62... .

I just took the way it appears in the documentation:

https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-cr...

I don't know why you refer to that page, but when you get to the business-end of that page, the "what to do bit", you find: *Minimum supported client* Windows XP [desktop apps | UWP apps] *Minimum supported server* Windows Server 2003 [desktop apps | UWP apps] *Target Platform* Windows *Header* synchapi.h (include Windows.h) *Library* Kernel32.lib *DLL* Kernel32.dll Where you can see that Windows.h is clearly capitalized (while other headers, clearly (and correctly) are not). Windows file system does not care whether it is capitalized or not, and

...

MinGW should not be sensitive to that.

It does actually, ntfs is case-sensitive. For backward compatibility (I presume), explorer, cmd.exe etc, add a case-insensitive layer on top of the native file-system. Clang-cl warns about mis-matches in casing. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*

Raffi Enficiaud

6:33 a.m.

On 22.03.19 06:32, degski via Boost wrote:

...

On Fri, 22 Mar 2019 at 02:13, Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:

...
On 19.03.19 16:08, Rainer Deyke via Boost wrote:

...
On 19.03.19 12:40, degski via Boost wrote:

...
On Tue, 19 Mar 2019 at 11:44, Rainer Deyke via Boost wrote:

...
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes instead of

The correct header should be/is 'Windows.h', it's capitalized, MinGW has a similar problem, IIRC.

It's not capitalized in the 30 instances of '#include ' in Boost header files, including 3 from Boost.Test, and it's not capitalized on my file system. It's also not capitalized on the Wikipedia page, it's not /consistently/ capitalized by Microsoft themselves, and even Microsoft are switching to lower case where portability matters: see

https://github.com/Microsoft/WinObjC/commit/9e55e2a7cb67fe9a4b3fffb491f7eb62... .

I just took the way it appears in the documentation:

https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-cr...

I don't know why you refer to that page, but when you get to the business-end of that page, the "what to do bit", you find:

This is the function that was pulling Windows.h and that was causing this issue.

...

*Minimum supported client* Windows XP [desktop apps | UWP apps] *Minimum supported server* Windows Server 2003 [desktop apps | UWP apps] *Target Platform* Windows *Header* synchapi.h (include Windows.h) *Library* Kernel32.lib *DLL* Kernel32.dll

Exactly, and every reference to Windows.h is with W. AFAIR, it was always like this.

degski

11:21 a.m.

On Fri, 22 Mar 2019 at 08:33, Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:

...

Exactly, and every reference to Windows.h is with W. AFAIR, it was always like this.

I misunderstood the intent of what you we're saying. Whatever commits do, whatever MinGW does, fact is that Windows.h is capitalized (and always has been). Being sloppy about it goes un-punished on Windows due to the legacy of FAT(32) still en-grained in the OS, but bites elsewhere. I might be wrong but I'm quite sure I have run into this problem with MinGW in the past. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*

Peter Dimov

12:36 p.m.

degski wrote:

...

On Fri, 22 Mar 2019 at 08:33, Raffi Enficiaud via Boost wrote:

...
Exactly, and every reference to Windows.h is with W. AFAIR, it was always like this.

I misunderstood the intent of what you we're saying. Whatever commits do, whatever MinGW does, fact is that Windows.h is capitalized (and always has been).

Your "always" doesn't go far back enough. It's capitalized in VS2005, and I have no earlier versions here to check, but my memory tells me that there was a time it wasn't. Borland 5.5.1 doesn't capitalize it, and windowsx.h is not capitalized in the Platform SDK. Plus, all Windows programming examples and books I remember used #include , without capitalization.

degski

1:28 p.m.

On Fri, 22 Mar 2019 at 14:37, Peter Dimov via Boost wrote:

...

Plus, all Windows programming examples and books I remember used #include , without capitalization.

Casual verification confirms this. Aesthetically [and if not just for simplicity], I would like them to be all minors, all of them, but they are not :-(. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*

Raffi Enficiaud

7:31 p.m.

On 22.03.19 13:36, Peter Dimov via Boost wrote:

...

degski wrote:

...
On Fri, 22 Mar 2019 at 08:33, Raffi Enficiaud via Boost wrote:

...
Exactly, and every reference to Windows.h is with W. AFAIR, it was > always like this.

I misunderstood the intent of what you we're saying. Whatever commits do, whatever MinGW does, fact is that Windows.h is capitalized (and always has been).

Your "always" doesn't go far back enough. It's capitalized in VS2005, and I have no earlier versions here to check, but my memory tells me that there was a time it wasn't. Borland 5.5.1 doesn't capitalize it, and windowsx.h is not capitalized in the Platform SDK. Plus, all Windows programming examples and books I remember used #include , without capitalization.

Yes, as far as I remember (AFAIR), which is the context of "always". My English has "always" been a bit broken. All in all, this is a non-issue on Windows, and I failed to catch the problem before it reached master with my CI. It is good that this has been caught before the release. Does anyone cross-compile for Windows on Travis? Raffi

Marshall Clow

19 Mar 19 Mar

3:11 p.m.

On Tue, Mar 19, 2019 at 2:43 AM Rainer Deyke via Boost < boost@lists.boost.org> wrote:

...

On 13.03.19 15:49, Marshall Clow via Boost wrote:

...
For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>.

Please download the beta, give it a try, and report any problems you encounter.

I want to report a problem.

Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes instead of on line 32 of boost/test/utils/timer.hpp.

I did a quick grep through the boost sources, and found: * About 250 #includes of "windows.h" (all lower case) * Zero #includes of "Windows.h" (upper-case 'W') (and a reference to changing one instance in Boost.Test from "Windows.h" to "windows.h" for 1.67.0) We may or may not be correct, but we're quite consistent. -- Marshall

mike.dev＠gmx.de

3:47 p.m.

...

-----Original Message----- From: Boost On Behalf Of Marshall Clow via Boost Sent: Tuesday, March 19, 2019 4:11 PM To: boost@lists.boost.org List Cc: Marshall Clow ; Rainer Deyke ; Boost users list Subject: Re: [boost] [release] Boost 1.70.0 Beta 1 is now available

On Tue, Mar 19, 2019 at 2:43 AM Rainer Deyke via Boost < boost@lists.boost.org> wrote:

...
On 13.03.19 15:49, Marshall Clow via Boost wrote:

...
For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>.

Please download the beta, give it a try, and report any problems you encounter.

I want to report a problem.

Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes instead of on line 32 of boost/test/utils/timer.hpp.

I did a quick grep through the boost sources, and found: * About 250 #includes of "windows.h" (all lower case) * Zero #includes of "Windows.h" (upper-case 'W') (and a reference to changing one instance in Boost.Test from "Windows.h" to "windows.h" for 1.67.0)

We may or may not be correct, but we're quite consistent.

FYI: On my windows 10 machine, the file(s) inside the windows sdks are called "Windows.h". All "windows.h" files on my machine come from mingw or boost itself (which sounds like a bad idea TBH).

...

-- Marshall

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

Raffi Enficiaud

22 Mar 22 Mar

12:04 a.m.

On 19.03.19 10:43, Rainer Deyke via Boost wrote:

...

On 13.03.19 15:49, Marshall Clow via Boost wrote:

...
For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>.

Please download the beta, give it a try, and report any problems you encounter.

I want to report a problem.

Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes instead of on line 32 of boost/test/utils/timer.hpp.

Fixed in master, thanks to Marshall for letting me merge this. I have not seen the message earlier. Raffi

Rainer Deyke

21 Mar 21 Mar

9:30 a.m.

On 13.03.19 15:49, Marshall Clow via Boost wrote:

...

Please download the beta, give it a try, and report any problems you encounter.

I would like to report another error, triggered when cross-compiling for MacOS on a Linux host. The following minimal test program fails to compile: #include "boost/container/flat_map.hpp" int main() { boost::container::flat_map m1, m2; m1.insert(m2.begin(), m2.end()); } Although the problem is triggered by Boost.Container, the actual error appears to be in Boost.Move. On line 958 of boost/move/algo/detail/merge.hpp, the function merge_adaptive_ONlogN_recursive is called with length arguments of mixed types if size_type != size_t, thereby preventing the compiler from instantiating the merge_adaptive_ONlogN_recursive function template. -- Rainer Deyke (rainerd@eldwood.com)

2076

Age (days ago)

2085

Last active (days ago)

List overview

Download

14 comments

6 participants

participants (6)

degski
Marshall Clow
mike.dev＠gmx.de
Peter Dimov
Raffi Enficiaud
Rainer Deyke