[swift-dev] [RFC] Finer grained OS checks

[Erica Sadun]

Just want to throw this into the discussion: 

* https://github.com/apple/swift-evolution/pull/369

Also discussions on -evolution, which do touch on "Apple-like", etc.

* http://thread.gmane.org/gmane.comp.lang.swift.evolution/7516
* http://thread.gmane.org/gmane.comp.lang.swift.evolution/12065

-- E

> On Jul 7, 2016, at 8:19 PM, Jordan Rose via swift-dev <swift-dev at swift.org> wrote:
> 
> Thanks for sending this out, Saleem!
> 
> I’m not convinced that gnu/uclibc/musl are environment variants worth testing for, nor do I think we actually want to model Android as a kind of Linux. It’s unclear whether “environment” is another set of mutually-exclusive options (enum-like) or a way to check several things that might all be true (option-set-like). For example, is “itanium” really distinct from all the others, or can you have itanium-gnu?
> 
> I imagine some people might like to distinguish Linux distros as well, but since those follow the “like Gecko <https://www.nczonline.net/blog/2010/01/12/history-of-the-user-agent-string/>” policy, I’m not sure we’d actually want to encourage people to use such a thing. On the other hand, we could easily have ‘environment(simulator)’ for the Apple device OSs.
> 
> It’s also not clear whether we always want ‘environment' to be a subset of ‘os', i.e. it’s a mistake to test for “simulator” before checking for an OS because it might mean different things on different platforms. (iOS simulator or Android simulator?)
> 
> I’ll defer to all of you as to whether “gnu” and “cygnus” are the right names for MinGW and Cygwin. I kind of thought Cygnus was named as such because it was also a GNU environment.
> 
> A related use is something that’s above `os(…)`, so that we can have all the Apple platforms grouped together. That could be “environment”, or it could be something different.
> 
> Finally, in the spirit of “question everything”, is “environment” the right name for this setting? :-)
> 
> The goal of this thread should be for you/us to converge on a design, and then for someone to write it up and take to swift-evolution.
> 
> Jordan
> 
> 
>> On Jul 7, 2016, at 18:17, Saleem Abdulrasool <compnerd at compnerd.org <mailto:compnerd at compnerd.org>> wrote:
>> 
>> Hi,
>> 
>> Id like to revive the discussion around OS "variants".  I've been doing some work to bring up Windows without any emulation layer (MSVCRT based) as a viable host environment.  This work is bringing to light the need for more finer grained OS checks.
>> 
>> Currently, we have the `os` compilation condition.  However, this doesn't provide sufficiently detailed information for Windows.  On Windows, we have at least 4 different "variants":
>> 
>> - "msvc" (Microsoft's environment)
>> - "itanium" (MS ABI for C, Itanium ABI for C++)
>> - "gnu" (MinGW)
>> - "cygnus" (cygwin)
>> 
>> Each one of these is slightly different and requires particular handling in the runtime.  However, the OS for each one of these is windows, and so `os(Windows)` yields true on all of them.
>> 
>> This is not a problem strictly limited to Windows.  It also appears in other OSes.  As a concrete example, Linux has traditionally had the "gnu" environment (libc).  However, there is also "uclibc" which is pretty common, and these days, "musl" as different targets.  Swift also supports android, which is a Linux environment variant.
>> 
>> As deeper system integration occurs with swift, the need for finer grained os detection logic is probably going to be needed.
>> 
>> To keep things simple, I would like to propose the "environment" conditional compilation directive.  It would yield true for the appropriate environment with one of the previously mentioned values for windows and true for "android" on Android.  It would sit as a peer to `os` and allow for finer grained querying of the host environment.
>> 
>> -- 
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160707/12da26ee/attachment.html>