[swift-users] Improving a simple C binding

[Jason Dusek]

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`.

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.

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.

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.

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.

Best,
  Jason

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

> > Behold, a binding for libpq:
> >
> >  https://github.com/solidsnack/CLibPQ
> >
> > And a little app that uses it:
> >
> >  https://github.com/solidsnack/PGVersion
> >
> > CLibPQ is put together in the simplest way: there's a module.modulemap
> > at the root and that's it. I would like to make some changes to the
> > module hierarchy and I'm not sure how to go about it. Here's what I'd
> > like to do:
> >
> > * Create `CLibPQ.OSXHomebrew` and `CLibPQ.Ubuntu` that contain the
> > right mappings for those platforms (the header files are in different
> > places).
> >
> > * Create `CLibPQ` that conditionally imports the right one:
> >
> >    CLibPQ.swift:
> >      #if os(Linux)
> >      import CLibPQ.Ubuntu
> >      #else
> >      import CLibPQ.OSXHomebrew
> >      #endif
> >
> > * In `PGVersion` we'd be able to `import CLibPQ` as before.
> >
> > What's the right project layout to make this work?
>
> You can’t do what you are trying here with a module map sadly.
>
> We need to add explicit support for this sort of thing to swiftpm. Our
> current ideas are:
>
> 1. Mangle the module map for obvious relocations (/usr -> /usr/local)
> 2. Making it possible to specify platform module maps for exceptions eg.
> Ubuntu.modulemap, etc.
> 3. Changing /usr to $ROOT and then having the user have to specify root if
> it is not /usr
>
> > Namespaced C modules are an interesting topic and worth pursuing in
> > their own right; but maybe there is a better way to do what I'm trying
> > to accomplish?
>
> I think namespaces needs discussion for Swift in general.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20151209/3ba2102c/attachment.html>