<div dir="ltr">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`.<div><br></div><div>Since we can't have macros in the module map, I think option (2) -- <span style="line-height:1.5">platform module maps -- would be a great combination of hygiene and flexibility (if tedious).</span></div><div><span style="line-height:1.5"><br></span></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Best,</div><div> Jason</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 9 Dec 2015 at 10:31 Max Howell <<a href="mailto:max.howell@apple.com">max.howell@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Behold, a binding for libpq:<br>
><br>
> <a href="https://github.com/solidsnack/CLibPQ" rel="noreferrer" target="_blank">https://github.com/solidsnack/CLibPQ</a><br>
><br>
> And a little app that uses it:<br>
><br>
> <a href="https://github.com/solidsnack/PGVersion" rel="noreferrer" target="_blank">https://github.com/solidsnack/PGVersion</a><br>
><br>
> CLibPQ is put together in the simplest way: there's a module.modulemap<br>
> at the root and that's it. I would like to make some changes to the<br>
> module hierarchy and I'm not sure how to go about it. Here's what I'd<br>
> like to do:<br>
><br>
> * Create `CLibPQ.OSXHomebrew` and `CLibPQ.Ubuntu` that contain the<br>
> right mappings for those platforms (the header files are in different<br>
> places).<br>
><br>
> * Create `CLibPQ` that conditionally imports the right one:<br>
><br>
> CLibPQ.swift:<br>
> #if os(Linux)<br>
> import CLibPQ.Ubuntu<br>
> #else<br>
> import CLibPQ.OSXHomebrew<br>
> #endif<br>
><br>
> * In `PGVersion` we'd be able to `import CLibPQ` as before.<br>
><br>
> What's the right project layout to make this work?<br>
<br>
You can’t do what you are trying here with a module map sadly.<br>
<br>
We need to add explicit support for this sort of thing to swiftpm. Our current ideas are:<br>
<br>
1. Mangle the module map for obvious relocations (/usr -> /usr/local)<br>
2. Making it possible to specify platform module maps for exceptions eg. Ubuntu.modulemap, etc.<br>
3. Changing /usr to $ROOT and then having the user have to specify root if it is not /usr<br>
<br>
> Namespaced C modules are an interesting topic and worth pursuing in<br>
> their own right; but maybe there is a better way to do what I'm trying<br>
> to accomplish?<br>
<br>
I think namespaces needs discussion for Swift in general.</blockquote></div>