Skip to content

build: use C++14 for Windows builds #13403

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 18, 2017
Merged

Conversation

compnerd
Copy link
Member

The Windows SDK headers require C++14 or newer features. Visual Studio
is lax in enabling these features unlike clang. Explicitly upgrade to
the higher standard for the Windows cross-compilation.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

The Windows SDK headers require C++14 or newer features.  Visual Studio
is lax in enabling these features unlike clang.  Explicitly upgrade to
the higher standard for the Windows cross-compilation.
@compnerd
Copy link
Member Author

CC: @troughton

@compnerd
Copy link
Member Author

@swift-ci please test

@troughton
Copy link
Contributor

troughton commented Dec 13, 2017

@compnerd I already have this in #13140, although mine’s a slightly different approach. Could you take a look at that before you merge this? This looks a little simpler so I could modify my PR to match (or remove those changes from mine).

@compnerd
Copy link
Member Author

@troughton #13140 changes the shared build which is used for the standalone builds. Did you actually test that portion of it? Also, I think that splitting up that PR into individual pieces is better as not all of it can be merged as is. This is ready to go ... but, I suppose that I can wait if you really want to split it up and submit a separate PR.

@jckarter
Copy link
Contributor

Concerns about MSVC support have long been the reason we've held out ratcheting up to C++14. If Microsoft's SDK requires C++14 now, is there any reason for us not to just move to C++14 unilaterally for all targets? I'd love to be able to use digit separators in my hex literals…

@compnerd
Copy link
Member Author

@jckarter fine by me, but that probably warrants an email to the ML to ensure that everyone is okay with that (I guess @tkremenek probably would make the call?).

@troughton
Copy link
Contributor

I can say that right now there’s something in the Swift project that fails on Linux with a C++14 standard, although I can’t remember what that was and won’t have the means to test that for a few hours.
I’m not sure whether it’d be a simple thing to fix or not.

As for this PR specifically: @compnerd I tested my changes only through the build-script invocation - I assume that by a standalone build you mean with a CMake invocation directly? And I don’t have any objection to you merging this in if you think it’s a better approach.

@compnerd
Copy link
Member Author

@troughton yeah, there is a mode to build just the SDK overlay with cmake. I think that leaving that untouched for now is a better option. I think that unblocking the Windows build is probably a good thing too. We can remove this when we move the entire project over to C++14, which might take a little bit of work as you point out that there are some issues. I'll merge this for now as a result, and work on moving the entire project to C++14 separately.

@compnerd compnerd merged commit 40e9499 into swiftlang:master Dec 18, 2017
@compnerd compnerd deleted the windows++14 branch December 18, 2017 18:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants