basic: introduce the _environment compilation conditional #3337
Conversation
|
CC: @jrose-apple |
|
@swift-ci Please test |
| switch (Target.getEnvironment()) { | ||
| default: break; | ||
| case llvm::Triple::MSVC: | ||
| addPlatformConditionValue("_environment", "msvc"); |
There was a problem hiding this comment.
Please add tests for these values to appropriate files in test/Parse/ConditionalCompilation.
There was a problem hiding this comment.
Im confused. How is the test below now sufficient?
Windows has multiple environment flavours, each of which are different. cygwin provides a glibc based environment, MinGW provides a msvcrt based GNU environment, itanium provides a msvc environment with an itanium C++ ABI, and msvc is the pure msvc, msvcprt based environment as vended by Microsoft. Due to the differences in the environment, we need a means to differentiate them at the stdlib level. Provide the _environment conditional which would allow you to query what environment is being targeted.
|
I'd rather not accept this right now unless we absolutely need it. Otherwise, it's worth actually going through swift-evolution and figuring out what |
|
@jrose-apple without this, unfortunately, it means that we can't do a windows port without breaking cygwin. Could we do both? |
|
Can you elaborate? What's something where the standard library needs different behavior between MSVC and Cygwin? |
|
Sure, there are cases where certain functions are available on cygwin and not in MSVCRT. Other cases are where they are just different. Because that may be a bit vague, lets take concrete examples: Just different: Unavailable: |
|
Hm, got it. I really don't want to introduce this because people will immediately start using it outside of the standard library. |
|
Im open to alternative suggestions. I don't know how long it would take to get through everything with the swift-evolution (especially since Ive not gone through it previously). |
|
Well, there's the hack of moving things into a C function for the few things that are different. |
|
What about the larger pieces like pthread (available on cygwin, not on msvc)? |
|
What about putting it behind a compiler flag? We already have one for the standard library, could it maybe fit inside |
|
If we really just want a workaround, we could also use an ad hoc -D flag. |
|
Sure, the ad-hoc -D flag sounds like it should be sufficient for now. I think that we should work out a proper environment check though. |
|
Oops, and @tinysun212. |
|
Thanks for your mention. I started similar discussion in #2351 and swift-evolution, but it is discontinued. I tried ad hoc -D flag in Foundation PR. In there, the code is like this. I think if we use the method 'ad hoc -D flag', we need the convention for the macro name. |
|
Ill definitely bring this up again. I used CYGWIN, as I don't want to break cygwin support as Im adding MSVCRT support. I have the work available on my own fork of the repository, and will be sending out a PR for a good chunk of it soon. |
What's in this pull request?
Resolved bug number: (SR-)
Before merging this pull request to apple/swift repository:
Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
Validation Testing
Lint Testing
Note: Only members of the Apple organization can trigger swift-ci.
Windows has multiple environment flavours, each of which are different. cygwin
provides a glibc based environment, MinGW provides a msvcrt based GNU
environment, itanium provides a msvc environment with an itanium C++ ABI, and
msvc is the pure msvc, msvcprt based environment as vended by Microsoft. Due to
the differences in the environment, we need a means to differentiate them at the
stdlib level. Provide the _environment conditional which would allow you to
query what environment is being targeted.