[swift-users] Improving a simple C binding

[Max Howell]

> 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 swift-build-dev at swift.org.

Max