[release] Boost 1.70.0 Beta 1 is now available
[ 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
On 13.03.19 15:49, Marshall Clow via Boost wrote:
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
On 19.03.19 12:40, degski via Boost wrote:
It's not capitalized in the 30 instances of '#include
On 19.03.19 16:08, Rainer Deyke via Boost wrote:
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
On Fri, 22 Mar 2019 at 02:13, Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:
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*
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*
degski wrote:
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
On Fri, 22 Mar 2019 at 14:37, Peter Dimov via Boost
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*
On 22.03.19 13:36, Peter Dimov via Boost wrote:
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
On Tue, Mar 19, 2019 at 2:43 AM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
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
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
participants (6)
-
degski -
Marshall Clow -
mike.dev＠gmx.de -
Peter Dimov -
Raffi Enficiaud -
Rainer Deyke