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

Eric Wing ewmailing at gmail.com
Fri Jan 15 09:11:42 EST 2016


Okay, I think I'm making some good progress. I got a trivial program
built on Mac. I've now switched to Linux. I'm mostly there, but there
are still some things that need to be done. More inline...


https://github.com/ewmailing/CMake/tree/SwiftMakefile


>> 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 got it working. I put it in.
CMakeSwiftCompiler.cmake.in
I figured out I also needed to add:
set(CMAKE_Swift_LINKER_PREFERENCE_PROPAGATES 1)



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

I looked at this file, but I still havne't groked what I need to do
with this yet.

However, I'm heavily debating if 'cc' or 'clang' is the right thing to
do here. I'm starting to think 'swiftc' might be the most robust and
correct thing for the linking command. There are several reasons for
this:

- swiftc seems to already do the right thing
- Not using swiftc requires me to set a lot of things, including the
Apple SDK when on Mac. This feels really messy.
- On Linux, I think there is a danger in calling 'cc'.




realized I may need to take a step back.


>

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


-- 
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/


More information about the cmake-developers mailing list