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

[William Dillon]

Hi all,

I Agree with Saleem that this is a worthwhile discussion, and I think I agree with Jordan that word environment seems a little bit wrong to me.

Following the discussion, it feels to me like what we're really concerned about is libc and ABI.  Most of the examples that Saleem gave seems to have that in common.  Jordan's example about environment(simulator) feels like a more natural fit (i.e. using it as a way to talk about the physical/virtual environment).  I think that libc(gnu), etc., would be perhaps workable, but doesn't express the differences in ABI for the Itanium example.

I do like Erica's contribution of the Evolution proposal from a bit ago. Adding libc to it with a combined check for arch should get is substantially there.

I know that I'm rambling bit; my thoughts on the subject are not fully formed.  I haven't been bitten by this particular issue yet, so it's of academic interest so far.

Thanks to all for their work,
- Will

> On Jul 7, 2016, at 7:19 PM, Jordan Rose <jordan_rose at apple.com> 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
> 

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