[swift-users] Improving a simple C binding

[Jason Dusek]

Well, I suppose it comes down to: are the OSes in os(...) strings or enums?

If they are strings then the compiler doesn’t need to be changed to add a
new OS — it just needs to have a standard way to look it up. For example it
might check lsb_release first, then try sw_vers. If the string there
presented matches something in an os(...) condition in a macro, then it
works. There is no internally maintained list of “valid OSes” so there is
no need to extend such a list to handle each new release of Ubuntu, Debian,
&c

On Wed, 9 Dec 2015 at 13:08, Max Howell <max.howell at apple.com> wrote:

> Another option would seem to be modelling the daylights out of build
>> environments but I think this runs afoul of enumerations. Right now we have
>> `os(Linux)` but we'd really need `os(Ubuntu)`, `os(RedHat)` and so forth to
>> handle dependencies like these. And if people are working on a new distro
>> -- or merely want a new platform tag even though they are on a stock distro
>> -- this would fail unless they rebuilt the Swift compiler or package
>> manager with an extended enumeration.
>>
>> Well, the module maps aren’t Swift so it wouldn’t work. Certainly we
>> could allow some kind of #if syntax in module maps, but I think the
>> elegance of one-file per platform will be enough and is much simpler.
>
> Maybe I wasn’t clear here. This passage is about the platform names — how
> do we keep discovery flexible? I’m assuming there is an enum somewhere —
> OSX, Linux, iOS — in the compiler and what I’d like to suggest is, a
> centralized registry like that will create maintenance headaches for
> maintainers and frustrate developers, too. So taking one file per platform
> as a given, as long as platform discovery is easily extended then porting
> libraries is easy — add a new platform file, or even pass the “compatible
> platform” as an option.
>
> I’m sorry, I don’t understand.
>
> ​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20151209/1e02a8fb/attachment.html>