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

[Brad King]

On 01/13/2016 06:17 PM, Eric Wing wrote:
> Under the hood, I think the LLVM linker can handle all of these
> through ld. But I think the thing that is tripping me up is that Swift
> seems to need to link against some additional libraries which are not
> needed in the pure C case. The swiftc command seems to know how to
> automatically link in those extra dependencies (and I don't need to
> add all the search paths to where the Swift core libraries are
> located).

That is the same as for C++.  See CMAKE_PARSE_IMPLICIT_LINK_INFO and
the call to it in "Modules/CMakeDetermineCompilerABI.cmake".  That is
responsible for extracting the implicit link information passed by a
given language compiler's front-end.  We'll need to extract that for
Swift.

> Anyway, I tried bumping up CMAKE_Swift_LINKER_PREFERENCE to 40. (Same
> as Java). But it didn't seem to do anything for me.

Where did you add the code to set it?

> I just tried not filtering the current primary file from the list. It
> still worked. So maybe we can get away with not filtering that.

Great.  It will be simplest to list all the sources in every call and then
repeat the one that is current.

> Anyway, it seems like adding SOURCES is the next step. Any hints on
> how to do that?

The cmLocalGenerator::ExpandRuleVariable method does the placeholder
substitution.  It relies on values in the RuleVariables structure
to be populated by the calling generator.  The Makefile generator
populates that for the compile line here:

 cmMakefileTargetGenerator::WriteObjectBuildFile

and the Ninja generator here:

 cmNinjaTargetGenerator::WriteCompileRule
 cmNinjaTargetGenerator::WriteObjectBuildStatement

Note that for Ninja we actually convert our placeholders to Ninja
rule placeholders and then provide the values on the actual build
statement line.

You should be able to call

 this->GeneratorTarget->GetObjectSources(objectSources, config);

to get the list of source files and then filter it based on
sf->GetLanguage().

The name "<SOURCES>" is not very good because it does not specify
how any filtering is done.  Perhaps a special case name such as
"<Swift-SOURCES>" would be better.

Do we know that there is a one-to-one mapping between libraries
and Swift modules?

-Brad