> In the case of `libpq`, even something obvious like `/usr -> /usr/local`
> wouldn't work because on Ubuntu it ends up in `/usr/include/postgres`.
Yes, I consider this quite a nasty issue that I’d like solve asap.
> Since we can't have macros in the module map, I think option (2) -- platform
> module maps -- would be a great combination of hygiene and flexibility (if
> tedious).
>
> As this gets fancier there will be a temptation to allow using very specific
> platform names -- Kubuntu-15.10 -- and there will be a need also for
> customization by the end user. I can't imagine that problems like this have
> not shown up for the iPhone dev team already, which has to support 3 major
> versions and a bunch of slightly variant kinds of ARM.
Yes, I think versioning will become necessary also. Which is problematic for
defining the semantic version of these module map packages. But can be done
easily as part of the filename:
KUbuntu-15.10.modulemap
We can bake in some obvious inheritance (Ubuntu is the parent “class” of
XUbuntu/KUbuntu etc.)
> One thought would be to expand macros in SwiftPM: allow macros in the module
> map. Then add an `sh()` macro to call the system shell. Now anything is
> possible! But this seems like an invitation to spurious dependencies and
> unreadable build files.
Indeed, we would like to avoid such things altogether if possible. We believe
that allowing arbitrary execution makes it harder for the tool to remain
reliable as people take further and further advantage. We want to avoid the
kinds of programmable configuration detection exhibited by the likes of
autoconf for as long as possible.
> 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.
> I'm sure you've thought a lot about all this stuff already and I'd like to
> know what you see as the way forward for Swift.
I think a combination of platform specific module maps with platform versions
and a Default.modulemap that details the standard layout for /usr which can
then be adapted to other prefixes will do the trick.
The Default.modulemap may be problematic, since as system-libraries evolve they
may change their installation layout. In my experience I have never seen this
happen to a stable library, but if we don’t take it into account we could
introduce a truly nasty situation in the future.
I’ll write up a full proposal to [email protected].
Max
_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
