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
|
|
|
|
(0039325)
|
Wojciech A. Koszek
|
2015-08-24 21:26
|
|
|
|
(0039339)
|
Brad King
|
2015-08-27 11:03
|
|
|
|
(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. |
|