MantisBT - CMake
View Issue Details
0015401CMakeCMakepublic2015-02-10 20:432016-06-10 14:31
Wojciech A. Koszek 
Kitware Robot 
lowfeaturealways
closedmoved 
Apple MacOS X10.4.10
CMake 3.1.1 
 
0015401: Add support for Swift language to CMake
I successfully use CMake for Xcode project generation. So I run cmake -GXcode followed by xcodebuild. It seems like right now cmake knows how to recognize .m files, but doesn't know how to handle .swift files.

It would be great to teach it that.
Tested on MacOSX Yosemite with cmake installed from "brew install cmake".

<CMakeLists.txt>
cmake_minimum_required (VERSION 2.6)
project (sample)
add_executable(sample ../sample.swift)

<cmake -GXcode>
[wkoszek-macbook:~/github/macb/obj] wkoszek% cmake -GXcode
-- Configuring done
-- Generating done
CMake Error: CMake can not determine linker language for target: sample
CMake Error: CMake can not determine linker language for target: sample
CMake Error: CMake can not determine linker language for target: sample
CMake Error: CMake can not determine linker language for target: sample
CMake Error: CMake can not determine linker language for target: sample
CMake Error: CMake can not determine linker language for target: sample
CMake Error: CMake can not determine linker language for target: sample
CMake Error: CMake can not determine linker language for target: sample
-- Build files have been written to: /Users/wkoszek/github/macb/obj


No tags attached.
Issue History
2015-02-10 20:43Wojciech A. KoszekNew Issue
2015-02-11 08:26Brad KingSeveritytweak => feature
2015-02-11 08:26Brad KingStatusnew => acknowledged
2015-02-11 08:26Brad KingSummaryCmake Xcode project generation doesn't support Swift language => Add support for Swift language to CMake
2015-06-13 15:52Eric WingNote Added: 0038919
2015-06-14 08:29Eric WingNote Added: 0038920
2015-06-15 08:32Brad KingNote Added: 0038921
2015-06-15 22:43Eric WingNote Added: 0038931
2015-06-16 08:30Brad KingNote Added: 0038933
2015-06-17 05:09Eric WingNote Added: 0038941
2015-06-19 10:51Brad KingNote Added: 0038957
2015-08-24 21:26Wojciech A. KoszekNote Added: 0039325
2015-08-27 11:03Brad KingNote Added: 0039339
2016-06-10 14:29Kitware RobotNote Added: 0042713
2016-06-10 14:29Kitware RobotStatusacknowledged => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0038919)
Eric Wing   
2015-06-13 15:52   
Yes, this is becoming more important. Where Obj-C was once mixed into cross-platform projects for the Mac/iOS backends, Swift is now being intermixed as well and will continue to be more common.

Additionally, Swift is going to be open sourced soon (Linux announced). So having a general solution to support Swift in CMake would be really great.

If say I, or anybody wanted to start tackling this, what should we look at specifically in the CMake source to do this?

From the Xcode side, I'm guessing Swift files need to be added and categorized as 'Swift Source' in Xcode. Additionally, the Xcode option for a Obj-C bridging header will need to be filled in for most cross-projects that interface with C. Also the Xcode options for Obj-C Generated Interface Header and possibly Install Obj-C compatibility header need to be passed. There are additional Swift specific sections for Swift optimization levels and Swift other flags.

Longer term, we'll want to look at the Makefile generator and how to call all these things from the command line, particularly for Linux support, but I think just starting with the Xcode generator would be a great first start.
(0038920)
Eric Wing   
2015-06-14 08:29   
I took an initial stab.

In cmGlobalXCodeGenerator.cxx in the function GetSourcecodeValueFromFileExtension(), I added swift right after the Obj-C entries.

  else if (ext == "swift")
    {
    sourcecode += ".swift";
    }

This correctly set the source code type in Xcode for Swift files. However, every Swift file was lacking any target association (blank checkboxes for all targets). This means no Swift files were getting compiled.


After some random guessing, I found in CMakeCCompiler.cmake.in, adding swift to the CMAKE_C_SOURCE_FILE_EXTENSIONS, would cause the Swift files to be correctly associated with a target.
set(CMAKE_C_SOURCE_FILE_EXTENSIONS c;m;swift)

I'm not sure if this is the right thing, but it seems to work. Guidance would be appreciated.
(0038921)
Brad King   
2015-06-15 08:32   
Re 0015401:0038920: Thanks for looking into it. Swift should be treated as a first-class language by CMake such that one might write "enable_language(Swift)" or list it among the languages given to the project() command. There is some basic information in Modules/CMakeAddNewLanguage.txt about how to get started on this.
(0038931)
Eric Wing   
2015-06-15 22:43   
Okay, I started by copying the C module versions to the following Swift files:

    CMakeDetermineSwiftCompiler.cmake
    CMakeSwiftCompiler.cmake.in
    CMakeSwiftInformation.cmake
    CMakeTestSwiftCompiler.cmake

But I’m getting pretty overwhelmed now trying to figure out how to convert these to Swift. Right now, I’m failing to detect the Swift compiler when I add enable_language(Swift). I’m getting pretty lost in the compiler id sections.

Can we reduce the task down to something simpler to get something going?

For the first and simplest case, we should leverage Xcode. Xcode already knows how to handle Swift files automatically. The most common case right now is that C/Obj-C/Swift files are intermixed in the same project. So additionally, it would be nice to not require enable_language(Swift) explicitly on Apple platforms, sort of like Obj-C, since it is kind of required to be available now. So for this first case, I would like to get back to something that built, without needing the prior hack of:
set(CMAKE_C_SOURCE_FILE_EXTENSIONS c;m;swift)

Then maybe for the next step, we can look at the Makefile, command line invocation. The compiler name is ‘swiftc’.

Unlike C, Swift doesn’t really have a preprocessor or linker. Also, I don’t think there is any dependency management you have to do as I think the compiler takes responsibility for that. So the only thing a higher-level build system is needed for is intermixing C/Obj-C/C++ files, linking C/Obj-C libraries, and bundling of asset files (e.g. icons, images, etc.)

(I’d like to skip thinking about Swift-only libraries right now too. Non-Swift-only libraries can be thought of as Obj-C libraries, and I think can be handled by the Obj-C system.)


So I think a lot of the code in the CMakeLANG files can go away, but I’m kind of overwhelmed. There seem to be a lot of implicit dependencies which I am not familiar with. (I tried gutting the compiler ID stuff since there is only one swift compiler right now, but I couldn’t make that work so far.)


So based on this information, can you specify what the bare minimum variables I need to set are to get that base case running again. Hard coded constants might be good for understanding for now.
(0038933)
Brad King   
2015-06-16 08:30   
Re 0015401:0038931: It would be better to discuss this on the developer mailing list.
(0038941)
Eric Wing   
2015-06-17 05:09   
I made a little bit of progress by using Java instead of C as a starting point.
But I'll move to the mailing list.
(0038957)
Brad King   
2015-06-19 10:51   
For reference, the mailing list thread is here:

 Adding Swift support to CMake
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13468 [^]
(0039325)
Wojciech A. Koszek   
2015-08-24 21:26   
Thanks for the changes. I'd like to see them brought to Cmake, since I'd like to provide Swift feedback in my MacB:

https://github.com/wkoszek/macb [^]
(0039339)
Brad King   
2015-08-27 11:03   
Some changes are already in CMake:

 Add rudimentary support for the Apple Swift language with Xcode
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531 [^]
(0042713)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.