> > 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.
_______________________________________________ swift-users mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-users
