[cmake-developers] Adding Swift support to CMake for Linux/Makefiles

[Eric Wing]

> Yes.  A few months ago I spent a few hours looking at the commands Xcode
> uses to build Swift code.  For reference, here are some notes I took
> (not well organized):
>
> ----------------------------------------------------------------------------
> MergeSwiftModule produces .swiftmodule files, which seem to be serialized
> copies of swift modules, like binary headers, each covering an entire module
> over multiple source files.  MergeSwiftModule merges partial modules from
> individual sources into one for the whole module.
>
> The .swiftmodule for a shared library can be consumed while compiling
> other projects whose "import" statements search the -I path for the
> .swiftmodule files.  The .swiftmodule file is a binary header for the
> whole shared library.
>
> The compiler leaves in .o files a decl that tells the linker what libraries
> to link.  The linker hopefully tolerates seeing those libraries explicitly
> on the command line too, since CMake will generate those.
>

That article I linked to also mentions the .swiftmodule system via swiftc.

=========
swiftc -emit-library translator.swift -module-name translator
-import-objc-header bridgingHeader.h
clang -shared -o libtranslator.so translator.o

# Now, create the module:
swiftc -emit-module -module-name translator translator.swift
-import-objc-header bridgingHeader.h

# This leaves us with three files: libtranslator.so,
translator.swiftmodule, and translator.swiftdoc.


# You must have a translator.swiftmodule in your module search path,
which we add with -I.:
swiftc -I. -c main.swift -import-objc-header bridgingHeader.h

# Let’s link everything together:
swiftc -o translate.exe jsonparse.o main.o -L. -ltranslator -lcurl
-ljson-c -lswiftGlibc -lFoundation
=========

I haven't given deep thought to libraries yet (still just trying to
get applications going), I'm thinking ADD_LIBRARY most needs to just
invoke the -emit-library flag on swiftc, and automatically add the -I
(include path) to the output directory for the linking. Maybe
-module-name can be inferred from the TARGET name?




> See the -emit-dependencies and output file map options to control where .d
> files are generated.
>
> swift -help
> swift -help-hidden
> swift -frontend -help
> swift -frontend -help-hidden
>
> If one imports a library written in C/objc then something generates a
> module map pointing to the headers.  It seems to lazily generate from
> the headers a module that can be loaded.  To use a C library from Swift
> one must write a module map explicitly.  Some lib providers may support
> modules directly and provide the module map next to the library file.

It looks like the 'swift' front-end build and packaging system is
still a work in progress and doesn't seem to fully work on Linux yet.


> Swift does have conditional compilation that affects imports.

Yes. I'm wondering at least with a swiftc backend, this is up to the
user to manually specify (mirror) in the CMake description to say what
files are compiled/linked, like they do now with C/C++/Obj-C.

Maybe when the 'swift' front-end gets farther, we can try to make this
more automatic. But since the 'swift' front-end is entangled with git,
and introduces its own package file conventions, it's not something
I've given much thought to.



Anyway, I have a couple of hours on a train this weekend. I was
wondering if you could give me guidance on what I need to do to get a
simple 'swiftc' integration going for ADD_EXECUTABLE, as described in
the original post.

Thanks,
Eric