<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Just want to throw this into the discussion: </div><div class=""><br class=""></div><div class="">* <a href="https://github.com/apple/swift-evolution/pull/369" class="">https://github.com/apple/swift-evolution/pull/369</a></div><div class=""><br class=""></div><div class="">Also discussions on -evolution, which do touch on "Apple-like", etc.</div><div class=""><br class=""></div><div class="">* <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/7516" class="">http://thread.gmane.org/gmane.comp.lang.swift.evolution/7516</a></div><div class="">* <a href="http://thread.gmane.org/gmane.comp.lang.swift.evolution/12065" class="">http://thread.gmane.org/gmane.comp.lang.swift.evolution/12065</a></div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jul 7, 2016, at 8:19 PM, Jordan Rose via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Thanks for sending this out, Saleem!</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">I imagine some people might like to distinguish Linux distros as well, but since those follow the “<a href="https://www.nczonline.net/blog/2010/01/12/history-of-the-user-agent-string/" class="">like Gecko</a>” 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.</div><div class=""><br class=""></div><div class=""><div class="">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?)</div></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">A related use is something that’s <i class="">above</i> `os(…)`, so that we can have all the Apple platforms grouped together. That could be “environment”, or it could be something different.</div><div class=""><br class=""></div><div class="">Finally, in the spirit of “question everything”, is “environment” the right name for this setting? :-)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 7, 2016, at 18:17, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" class="">compnerd@compnerd.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hi,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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":</div><div class=""><br class=""></div><div class="">- "msvc" (Microsoft's environment)</div><div class="">- "itanium" (MS ABI for C, Itanium ABI for C++)</div><div class="">- "gnu" (MinGW)</div><div class="">- "cygnus" (cygwin)</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.<br class=""><br class="">As deeper system integration occurs with swift, the need for finer grained os detection logic is probably going to be needed.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">-- <br class=""><div data-smartmail="gmail_signature" class="">Saleem Abdulrasool<br class="">compnerd (at) compnerd (dot) org</div>
</div></div>
</div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-dev mailing list<br class=""><a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-dev<br class=""></div></blockquote></div><br class=""></body></html>