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

[Brad King]

On 02/29/2016 06:59 AM, Eric Wing wrote:
> I see in the CMakeSwiftInformation.cmake, there is a
> . However, I do not see a ,
> just .

That  is implicitly the flags for the corresponding language
since it appears in the compilation rule specific to the language.

> Additionally, in regular CMake script, I was trying to set/use
> ${CMAKE_Swift_FLAGS} hoping it would just work, but it doesn't seem to
> have any effect. Is this something I'm going to have to implement in
> the C++ core?

For the Makefile generator take a look at

 cmMakefileTargetGenerator::WriteTargetLanguageFlags
 cmMakefileTargetGenerator::WriteObjectBuildFile

methods.  They generate a _FLAGS variable in the makefile and
reference it.  Make sure those code paths are executed for Swift.
There should be similar code for the Ninja generator too.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Eric Wing]

I'm finding that I'm going to need to completely separate the C FLAGS
from the Swift FLAGS. I hit some complicated situations where the C
FLAGS (both compile and linker) are confusing the process and
shouldn't be passed to Swift.

I see in the CMakeSwiftInformation.cmake, there is a
. However, I do not see a ,
just .

Additionally, in regular CMake script, I was trying to set/use
${CMAKE_Swift_FLAGS} hoping it would just work, but it doesn't seem to
have any effect. Is this something I'm going to have to implement in
the C++ core?

Thanks,
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Eric Wing]

On 2/4/16, Brad King  wrote:
> On 01/29/2016 03:16 PM, Eric Wing wrote:
>> I need more guidance here. I'm not connecting the dots.
>> My problem seems to be that the execute_process() in
>> CMakeDetermineCompilerId.cmake is trying to invoke the command:
>> 'swift CompilerId/main.swift'
> [snip]
>> Looking at the execute_process() that gets invoked (final one in the
>> big if/elseif block of CMAKE_DETERMINE_COMPILER_ID_BUILD), the only
>> way to get the flags I need are via CMAKE_${lang}_COMPILER_ID_FLAGS.
>
> Some refactoring may be needed to allow language-specific behavior
> to add flags that must be there for the check.  Add an explicit
> internal variable or other code path to support it (that is just
> not set for other languages).  The semantics of selecting flags
> from the environment in CMAKE_${lang}_COMPILER_ID_FLAGS must not
> change.
>
> Thanks,
> -Brad
>
>

Okay, thanks, will do.

A quick update on my progress.

- I started looking at the DEFINE system for Swift. It has a very
simplified form of what we would do in C. You can doo -DFOO for
#if FOO
// do something
#endif

But it doesn't allow for anything more complicated like values. So
this is not supported: -DFOO=1

So currently there doesn't seem to be any compiler failure, it just
doesn't do anything useful.

Currently I'm using ADD_DEFINITIONS. And that works. However, since
this blends C/C++/Obj-C/Swift into the same pool, it doesn't feel
right. (I think Xcode has separate definitions for Swift.) Right now
if I'm clever and don't pick any definitions that conflict, I can use
the system. And the more complex ones are simply ignored by Swift. But
longer term, I'm thinking these may need to be split up.


- Second, I got word from a Swift engineer that the 'swift' frontend
compiler is not a supported tool and can break the interface. I should
be using swiftc. Furthermore, I was told that the file-by-file
compilation which 'swift' allows is not really supported and the
output I'm seeing from Xcode is more debug information than what's
really going on. They seemed adamant that the all files in one-shot
via swiftc was the correct path and what I was doing was unreliable
and also loses information for the debugger and libraries.

Anyway, I'm still reflecting on this about what to do next. The
reality is that what I have right now works (for me), and solves a
bunch of problems that their current tools do not solve (Xcode is more
proof of that). The current path has pretty minimal changes to CMake
as well. I'm still reflecting and will probably need to press them for
more specifics, but based on all the realities of the situation, I'm
thinking I should press on with this initial implementation to get
something useable if not perfect. But longer term, we probably need to
look at swiftc and one-shot.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Brad King]

On 01/29/2016 03:16 PM, Eric Wing wrote:
> I need more guidance here. I'm not connecting the dots.
> My problem seems to be that the execute_process() in
> CMakeDetermineCompilerId.cmake is trying to invoke the command:
> 'swift CompilerId/main.swift'
[snip]
> Looking at the execute_process() that gets invoked (final one in the
> big if/elseif block of CMAKE_DETERMINE_COMPILER_ID_BUILD), the only
> way to get the flags I need are via CMAKE_${lang}_COMPILER_ID_FLAGS.

Some refactoring may be needed to allow language-specific behavior
to add flags that must be there for the check.  Add an explicit
internal variable or other code path to support it (that is just
not set for other languages).  The semantics of selecting flags
from the environment in CMAKE_${lang}_COMPILER_ID_FLAGS must not
change.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Eric Wing]

On 1/20/16, Brad King  wrote:
> On 01/20/2016 08:48 AM, Eric Wing wrote:
>> I thought maybe setting the internal
>> CMAKE_${lang}_COMPILER_ID_FLAGS_LIST or
>> CMAKE_${lang}_COMPILER_ID_FLAGS
>> to "-version" would fix this.
>>
>> But this did nothing.
>
> Those are internal details of the CMAKE_DETERMINE_COMPILER_ID
> function and are not meant to be set anywhere else.  I think you
> may be looking for something like this:
>
> https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.4.2#l122
>
> It is used by the CMAKE_DETERMINE_COMPILER_ID_VENDOR fallback when
> the compiler id cannot be extracted from the basic compiler output.
> More work may be needed to also extract a version number through
> the CMAKE_DETERMINE_COMPILER_ID_VENDOR infrastructure.

I need more guidance here. I'm not connecting the dots.
My problem seems to be that the execute_process() in
CMakeDetermineCompilerId.cmake is trying to invoke the command:
'swift CompilerId/main.swift'

This will cause swift to run in REPL mode which won't return.
It is not passing any of the flags I taught CMake to use when trying
to compile a Swift program.

Looking at the execute_process() that gets invoked (final one in the
big if/elseif block of CMAKE_DETERMINE_COMPILER_ID_BUILD), the only
way to get the flags I need are via CMAKE_${lang}_COMPILER_ID_FLAGS.
But there is a block at the top of the file which overwrites the
variables. I was suggesting list(APPEND) instead of set() would fix
that problem, and in fact look suspicious to me since there is no way
to access those values passed to execute_process().

  if(CMAKE_${lang}_FLAGS)
#set(CMAKE_${lang}_COMPILER_ID_FLAGS ${CMAKE_${lang}_FLAGS})
list(APPEND CMAKE_${lang}_COMPILER_ID_FLAGS ${CMAKE_${lang}_FLAGS})
  else()
#set(CMAKE_${lang}_COMPILER_ID_FLAGS $ENV{${flagvar}})
list(APPEND CMAKE_${lang}_COMPILER_ID_FLAGS $ENV{${flagvar}})
  endif()



>
> Yes.  One remaining question is if there is an established convention
> already out there for the name of the SWIFTFLAGS environment variable.
>

I haven't spotted anything so far. Remember that Xcode and anything
GUI based on Mac doesn't use environmental variables. So this isn't a
feature that the existing Apple community would be using.


Thanks,
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Brad King]

On 01/20/2016 08:48 AM, Eric Wing wrote:
> I thought maybe setting the internal
> CMAKE_${lang}_COMPILER_ID_FLAGS_LIST or
> CMAKE_${lang}_COMPILER_ID_FLAGS
> to "-version" would fix this.
> 
> But this did nothing.

Those are internal details of the CMAKE_DETERMINE_COMPILER_ID
function and are not meant to be set anywhere else.  I think you
may be looking for something like this:

 
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/CMakeDetermineFortranCompiler.cmake;hb=v3.4.2#l122

It is used by the CMAKE_DETERMINE_COMPILER_ID_VENDOR fallback when
the compiler id cannot be extracted from the basic compiler output.
More work may be needed to also extract a version number through
the CMAKE_DETERMINE_COMPILER_ID_VENDOR infrastructure.

> it looks like somehow I already have $ENV{SWIFTFLAGS} set to
> CMAKE_Swift_FLAGS_INIT in CMakeSwiftInformation.cmake. (Either you did
> it, or it was copy/paste/substitute from C.)

It looks like it came from your port from CMakeCInformation.  The

 set(CMAKE_Swift_FLAGS_INIT "$ENV{SWIFTFLAGS} ${CMAKE_Swift_FLAGS_INIT}")

line looks correct.

> So I can do this in my shell:
> export SWIFTFLAGS='-target armv7-unknown-linux-gnueabihf'
> 
> And CMake picks it up. Is this the correct expected behavior for CMake?

Yes.  One remaining question is if there is an established convention
already out there for the name of the SWIFTFLAGS environment variable.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Eric Wing]

On 1/19/16, Brad King  wrote:
> On 01/18/2016 01:51 PM, Eric Wing wrote:
>> So the good news is I have a basic add_executable working with Swift
>> on Linux via the Makefile generator.
>>
>> It works with all Swift files, or intermixed C+Swift files. Bridging
>> header is also supported.
>
> Great!
>
>> - I’m still copying over some CFLAGS to Swift_FLAGS. For example, I
>> couldn’t figure out what was providing the ‘-I’ flag for include
>> paths. Rules like this still need to be rewritten for Swift.
>
> Try adding to CMakeSwiftInformation:
>
>  set(CMAKE_INCLUDE_FLAG_Swift -I)
>
>> - TODO: I need to look at Swift's DEFINE system.
>
> Yes.  After we get things building correctly the first time then we'll
> also need to see about adding needed dependencies to the build system.
>
>> - Note: The new file is Linux-unknown-Swift.cmake. When I compile
>> Swift myself, there is no company or organization identifier (swift
>> --version) unlike the one Apple ships with Xcode, and CMake refers to
>> the identifier as ‘unknown’. I made the file reflect this, but maybe
>> we should rename this later (maybe Swift_org).
>
> In an earlier Swift thread there was discussion about the name of the
> compiler id and ``Apple`` was chosen because that is the vendor of
> their version.  We definitely need to choose an id besides "unknown"
> for this.  Perhaps ``SwiftOrg``?  Also, we need a good way to check
> the id.  We could use `--version` if necessary but do we know whether
> the language provides any kind of identifier for code to use for
> conditional compilation?
>
>> - To answer your question about whether ‘swift’ instead of ’swiftc’
>> can be used for linking, I think the answer is yes, but I have been
>> unable to figure out the correct incantation.
>
> Okay.  Let's go with the ``c`` hack until we
> know more.  I'd prefer not to have to expose a separate setting for
> the link driver only to remove it later.
>
>> - Swift Standard (or Core) Libraries: Swift comes with multiple
>> standard libraries.
> [snip]
>> I think CMake should provide some variables to the full paths to
>> these libraries since users like me will want to refer to them.
>
> Perhaps, but we currently don't do that for any other languages.
> We do provide CMAKE_{C,CXX,Fortran}_IMPLICIT_LINK_DIRECTORIES
> listing directories that may contain the standard libraries.
> This is the same as the information needed to use the C linker
> to mix languages that we previously discussed trying to extract
> for Swift.
>
> -Brad


Thanks for the response. I looking at version related stuff.
I've been trying to get things running on the Raspberry Pi (Raspbian).
I uncovered a few issues.

First, the CMake Swift compiler version check being run was actually
wrong all this time, but somehow got through on my desktop Linux. It
was calling swift without proper flags, so interactive (REPL) mode
should have run and blocked the process. Not sure how that got
through. But on the Pi, the REPL segfaults which made the problem
obvious.

To answer your other question about getting the version from within
Swift, I haven't figured out a way to do this yet. All the examples
are about getting the iOS version number or availability of APIs,
nothing about the language or compiler.

So via command line on Pi:
swift -version
Swift version 2.2-dev (LLVM cb23059150, Clang f66c5bb67b, Swift 7187741628)
Target: armv7-unknown-linux-gnueabihf


So to correct this crash (which is a blocking issue on Pi for CMake),
I want to pass the -version flag during that CMake check. But this
leads to another question.
I thought maybe setting the internal
CMAKE_${lang}_COMPILER_ID_FLAGS_LIST or
CMAKE_${lang}_COMPILER_ID_FLAGS
to "-version" would fix this.

But this did nothing. I tracked the code to the function definition of
CMAKE_DETERMINE_COMPILER_ID. I think there may be a bug:


function(CMAKE_DETERMINE_COMPILER_ID lang flagvar src)


  # Make sure user-specified compiler flags are used.
  if(CMAKE_${lang}_FLAGS)
set(CMAKE_${lang}_COMPILER_ID_FLAGS ${CMAKE_${lang}_FLAGS})
  else()
set(CMAKE_${lang}_COMPILER_ID_FLAGS $ENV{${flagvar}})
  endif()
  string(REPLACE " " ";" CMAKE_${lang}_COMPILER_ID_FLAGS_LIST
"${CMAKE_${lang}_COMPILER_ID_FLAGS}")


The CMAKE_${lang}_COMPILER_ID_FLAGS gets overwritten with generic
flags, not the compiler_id_flags and I don't think the
compiler_id_flags can ever be used.

I think set() in those cases should be list(APPEND ...)
Can you confirm?


Additionally, there seems to be another Swift/ARM bug where the
default target architecture name is slightly wrong. This causes the
compile object files phases to always fail. This isn't a CMake
problem, but to work around it, I want something like environmental
variable CFLAGS or CXXFLAGS to be picked up by CMake. Coincidentally,
it looks like somehow I already have $ENV{SWIFTFLAGS} set to
CMAKE_Swift_FLAGS_INIT in CMakeSwiftInformation.cmake. (Either you did
it, or it was copy/paste/substitute from 

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

[Brad King]

On 01/18/2016 01:51 PM, Eric Wing wrote:
> So the good news is I have a basic add_executable working with Swift
> on Linux via the Makefile generator.
> 
> It works with all Swift files, or intermixed C+Swift files. Bridging
> header is also supported.

Great!

> - I’m still copying over some CFLAGS to Swift_FLAGS. For example, I
> couldn’t figure out what was providing the ‘-I’ flag for include
> paths. Rules like this still need to be rewritten for Swift.

Try adding to CMakeSwiftInformation:

 set(CMAKE_INCLUDE_FLAG_Swift -I)

> - TODO: I need to look at Swift's DEFINE system.

Yes.  After we get things building correctly the first time then we'll
also need to see about adding needed dependencies to the build system.

> - Note: The new file is Linux-unknown-Swift.cmake. When I compile
> Swift myself, there is no company or organization identifier (swift
> --version) unlike the one Apple ships with Xcode, and CMake refers to
> the identifier as ‘unknown’. I made the file reflect this, but maybe
> we should rename this later (maybe Swift_org).

In an earlier Swift thread there was discussion about the name of the
compiler id and ``Apple`` was chosen because that is the vendor of
their version.  We definitely need to choose an id besides "unknown"
for this.  Perhaps ``SwiftOrg``?  Also, we need a good way to check
the id.  We could use `--version` if necessary but do we know whether
the language provides any kind of identifier for code to use for
conditional compilation?

> - To answer your question about whether ‘swift’ instead of ’swiftc’
> can be used for linking, I think the answer is yes, but I have been
> unable to figure out the correct incantation.

Okay.  Let's go with the ``c`` hack until we
know more.  I'd prefer not to have to expose a separate setting for
the link driver only to remove it later.

> - Swift Standard (or Core) Libraries: Swift comes with multiple
> standard libraries.
[snip]
> I think CMake should provide some variables to the full paths to
> these libraries since users like me will want to refer to them.

Perhaps, but we currently don't do that for any other languages.
We do provide CMAKE_{C,CXX,Fortran}_IMPLICIT_LINK_DIRECTORIES
listing directories that may contain the standard libraries.
This is the same as the information needed to use the C linker
to mix languages that we previously discussed trying to extract
for Swift.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Eric Wing]

On 1/15/16, Brad King  wrote:
> On 01/15/2016 09:47 AM, Eric Wing wrote:
>>> That is the same as for C++.  See CMAKE_PARSE_IMPLICIT_LINK_INFO and
>>
>> I looked at this file, but I still havne't groked what I need to do
>> with this yet.
>
> Somehow we need to get swift to print verbose output about the command
> line it uses to invoke the linker on the small test project CMake uses
> while enabling the language.  Then we need to parse that link line to
> get the list of libraries and link directories.  This can be a later
> step once most other things work though.
>
>> However, I'm heavily debating if 'cc' or 'clang' is the right thing to
>> do here.
>
> If the user sets LINKER_LANGUAGE to "C" and does not have main in Swift
> then CMake will want to link with the C compiler.  FYI, it is not actually
> 'cc' but the CMAKE_C_COMPILER selected, which happens to be 'cc' often.
> Anyway, we should go with CMAKE_Swift_COMPILER for now.
>
>> - First, CMake seems to be passing the flag -rdynamic to the link
>> instructions, and this is causing a "unknown argument" error. I think
>> this needs to be removed. I'm not sure where this flag is coming from.
>>
>> - Second, -Wl,-rpath,/foo/bar is also causing an "unknown argument"
>> error. As shown in the beginning of this thread, swiftc wants each
>> argument to lead with -Xlinker (and there is no -Wl,)
>> -Xlinker -rpath -Xlinker /foo/bar
>
> You'll need to add proper settings in files of the form
>
>  Modules/Platform/--.cmake
>  Modules/Compiler/-.cmake
>
> such as
>
>  Modules/Platform/Linux-Apple-Swift.cmake
>  Modules/Platform/Darwin-Apple-Swift.cmake
>  Modules/Compiler/Apple-Swift.cmake
>
> See Modules/Platform/Linux-NAG-Fortran.cmake for an example that
> changes from -Wl,-rpath to -Xlinker -rpath.  Similarly the
> CMAKE_SHARED_LIBRARY_LINK__FLAGS must not have -rdynamic
> in it.  You're getting the settings from C right now because
> your CMakeSwiftInformation.cmake file is copying them.  Instead
> leave all those out and add them as needed, preferably without
> copying from C.
>
>> Additionally, I realized I should have some other variable besides
>> 
>> Seems like I should have . I'm not sure what the
>> correct way to create this is.
>
> All the languages use CMAKE__COMPILER as the front-end to
> invoke for linking.  There should not need to be a separate linker
> value unless that is new to Swift semantics.
>
>> However, I currently employ a clever cheat. Since the compiler is
>> 'swift', and the linker is 'swiftc', I just do
>> 'c'
>
> So plain 'swift' cannot be used to drive the linker too?
>
>>> Note that for Ninja we actually convert our placeholders to Ninja
>>> rule placeholders and then provide the values on the actual build
>>> statement line.
>>
>> I actually don't' know anything about Ninja. I assume it is just a
>> string translation at this point since I did the other? Any guidance
>> on the mapping?
>
> Let's start with the Makefile generator.  Porting the results to
> the Ninja generator should not be too much work later.
>
>> So I need a new per-target variable in CMake for this and a way to
>> inject it into the compiler flags, maybe something like this:
>>
>>" -frontend -c   
>> -import-objc-header  -primary-file
>>   -emit-module -module-name  -o
>> ")
>>
>> With those two pieces, I think that actually makes add_executable()
>> usable in the Makefile generator.
>
> The values for the placeholders are always determined in the context
> of a specific target, so just "" should be
> fine.
>
> Thanks,
> -Brad
>
>


This email is intended to be positive news, though there will be a lot
of details about what still needs to be done or is not quite right
yet.

So the good news is I have a basic add_executable working with Swift
on Linux via the Makefile generator.

It works with all Swift files, or intermixed C+Swift files. Bridging
header is also supported.

I took one of my small, but non-trivial programs which does a lot with
CMake to package up resources (images, audio, etc) and set rpaths and
has lots of (C) dynamic libraries it links to which also get shipped
with the bundle to make a self-contained app (rpath), and ported the
core parts to Swift. CMake handled this pretty much transparently (had
to enable_language(Swift), set the bridging header, and there are
Swift Standard Library things to sort out later). So overall, I’m
really happy with this.



So now the details.

- I’m still copying over some CFLAGS to Swift_FLAGS. For example, I
couldn’t figure out what was providing the ‘-I’ flag for include
paths. Rules like this still need to be rewritten for Swift.

- TODO: I need to look at Swift's DEFINE system.

- Link flags for -rpath are now rewritten (and -rdynamic is removed)

- Added  set_target_property(my_exe SWIFT_BRIDGING_HEADER
“/foo/bar/mybridge.h”). There is a token in the .cmake description for
, but the full flag for -import-objc-header
/foo/bar/mybridge.h is generated in the C++ side. This is 

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

[Eric Wing]

(Ignore the last post. The last message sent accidentally before I was
even close to done. Not sure why it sent. I must have accidentally
discovered a hot key in Gmail. Everything is rewritten here.)


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


>> 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' because it could
be gcc or it could be an older version of clang. (Officially, clang
3.5 is needed, but the default one on the particular Linux I'm using
is less than that.) Invoking swiftc theoretically side-steps this
problem.


But if I use swiftc, I create a few new complications:

- First, CMake seems to be passing the flag -rdynamic to the link
instructions, and this is causing a "unknown argument" error. I think
this needs to be removed. I'm not sure where this flag is coming from.

- Second, -Wl,-rpath,/foo/bar is also causing an "unknown argument"
error. As shown in the beginning of this thread, swiftc wants each
argument to lead with -Xlinker (and there is no -Wl,)
-Xlinker -rpath -Xlinker /foo/bar

Again, I'm not sure where the old stuff is, and what is involved to
inject the -Xlinker stuff.


Additionally, I realized I should have some other variable besides

Seems like I should have . I'm not sure what the
correct way to create this is.

However, I currently employ a clever cheat. Since the compiler is
'swift', and the linker is 'swiftc', I just do
'c'




>  cmMakefileTargetGenerator::WriteObjectBuildFile
> You should be able to call
>  this->GeneratorTarget->GetObjectSources(objectSources, config);

Okay, I added this code. It seems to be working. Though I'm not
completely sure I fetched config correctly.

My current changes can be found here in the SwiftMakefile branch
https://github.com/ewmailing/CMake/tree/SwiftMakefile


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

I actually don't' know anything about Ninja. I assume it is just a
string translation at this point since I did the other? Any guidance
on the mapping?


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

Sorry, I'm still not completely up to speed on Swift modules. My
impression is there are 3 parts: .swiftmodule (which contains the
public interface/definitions), .swiftdoc (for documentation), and a
library (.a, .so). I suspect the .swiftmodule will need to be part of
the compile parameters and the library will be part of the link, but
I'm not sure if there will be additional requirements.


But anyway, I would like to get something building on Linux first, so
I need to fix the swiftc/linker stuff first. Any suggestions?

Then, I would like to enhance the trivial test to support actually
using something from the intermixed C files. This means I need to add
the bridging header parameter.
So I need a new per-target variable in CMake for this and a way to
inject it into the compiler flags, maybe something like this:

  " -frontend -c   
-import-objc-header  -primary-file
  -emit-module -module-name  -o
")


With those two pieces, I think that actually makes add_executable()
usable in the Makefile generator.

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

[Eric Wing]

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 "" is not very good because it does not specify
> how any filtering is done.  Perhaps a special case name such as
> "" 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/
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [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 "" is not very good because it does not specify
how any filtering is done.  Perhaps a special case name such as
"" would be better.

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

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Eric Wing]

On 1/12/16, Brad King  wrote:
> On 01/08/2016 06:15 PM, Eric Wing wrote:
>> simple 'swiftc' integration going for ADD_EXECUTABLE, as described in
>> the original post.
>
> Take the generator check out of Modules/CMakeDetermineSwiftCompiler.cmake
> to get rid of the up-front error.  See "Modules/CMakeAddNewLanguage.txt"
> (many of the steps are already done).
>
> Edit Modules/CMakeSwiftInformation.cmake and add settings for variables
> like CMAKE_Swift_COMPILE_OBJECT and CMAKE_Swift_LINK_EXECUTABLE.  See
> the CMake{C,CXX,Fortran}Information.cmake modules for examples.  The
> available placeholders are in cmLocalGenerator::ExpandRuleVariable.
>
> If all the compile/link steps used for C and C++ map well to switfc
> then it should be fairly straightforward.  If other steps are needed
> or the steps have wildly different semantics then more in-depth changes
> to the actual generators may be needed.
>
> -Brad
>


So I got the trivial base case working with swiftc (no library
dependencies, Mac for now but will shift to Linux eventually):
add_exectuable(MyTarget main.swift)

Yay.

So next I wanted to add more files to the mix. And now I have some problems.


Problem 1: Intermixing C and Swift
add_exectuable(MyTarget main.swift some_c.c)
Note: I presume C++ (and Obj-C) could also be in the mix:
add_exectuable(MyTarget main.swift some_c.c some_cpp.cpp some_objc.m)

It looks like the link phase is invoking cc on my system (the C linker
rules?) instead of the Swift linker commands.

If my hunch is correct, how do I tell CMake to ‘promote’ Swift as the
correct tool?
(Perhaps there is a similar existing mechanism already is handling
intermixing C/C++ or C/Obj-C?)

Additional note: I am a little surprised to see cc instead of ld (or
swiftc). Now I may be able to use cc or ld, but I need to figure out
how to adapt and add some additional flags. So it could be that I
could work around this problem. (Kind of working solution at the
bottom.)



Problem 2: Multiple Swift files in the target
add_exectuable(MyTarget main.swift OtherSwift.swift)

With two or more files, I was hoping to do a single one-shot call:
swiftc -c OtherSwift.swift main.swift -module-name MyTarget

But it looks like CMake invokes each file separately. The problem that
creates in the above case is that if main.swift uses stuff from the
other file, it can no longer compile because it is unable to find the
code in OtherSwift because they are treated as separate unconnected
modules. I haven’t figured a way yet around this using swiftc.

However, I can switch to the tool ‘swift’, but it looks like Swift has
a similar constraint which I will discuss shortly.

But before I move on to that, is there a way to get CMake to invoke
all the Swift files in the target together? (It would need to exclude
any non-Swift files in the list.)

I think there may be trade-offs here. On one hand, file-by-file might
get us incremental compilation. But there is a flag called
-whole-module-optimization which suggests treating them as a batch
could allow better code generation.


Now for the 'swift' tool:

So the swift tool can go file-by-file, but the additional constraint
is that all the other Swift files in the target must be listed too. To
distinguish which file is actually being processed, you must use the
-primary-file  . I think this is so
Swift can figure out all the cross-file dependencies since there are
no header files in Swift.

Here is an example of compiling my two files:

# Compile main.swift to main.o
swift -frontend -c -primary-file
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/main.swift
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/OtherSwift.swift
-emit-module -module-name MyTarget  -o CMakeFiles/MyApp.dir/main.o
-emit-module-path CMakeFiles/MyApp.dir/main~partial.swiftmodule

# Compile OtherSwift.swift to OtherSwift.o
swift -frontend -c -primary-file
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/OtherSwift.swift
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/main.swift
-emit-module -module-name MyTarget  -o
CMakeFiles/MyApp.dir/OtherSwift.o -emit-module-path
CMakeFiles/MyApp.dir/OtherSwift~partial.swiftmodule

Other things to notice:
- I am using the CMake Target Name for the -module-name
- There is a basename~partial.swiftmodule being generated. I'm not
completely sure why this is needed, but I see it in the Xcode build
lines and other examples on the web.


Finally, the link line can look like this: (Xcode invokes clang
instead of cc, but they map to the same thing on Mac)

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
 -arch x86_64 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
-L/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift_static/macosx
-Xlinker -force_load_swift_libs -lswiftRuntime -lc++ -framework

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

[Eric Wing]

> For the moment, I like swiftc over swift because it seems a lot
> simpler. I hope this means the least changes for CMake right now.

I need to correct myself on this. While I like swiftc for looking
simpler, I'm actually thinking swift might be fewer changes since the
file-by-file thing is what CMake does today.
It may turn out swift is easier to figure out in the end too when we
eventually look at add_library and linking them (since we can reverse
engineer from the Xcode logs).

But either way, both of them seem to need SOURCES.

Thanks,
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Eric Wing]

>> If my hunch is correct, how do I tell CMake to ‘promote’ Swift as the
>> correct tool?
>
> See the CMAKE__LINKER_PREFERENCE platform information variable.
> There is also the LINKER_LANGUAGE target property.  For C, C++, and
> Fortran one generally chooses between C++ and Fortran to drive the
> linker based on which language has the entry point (main) in its
> sources.  If we see a "main.swift" then we know Swift should be used.
> If not then I don't know enough about Swift linking requirements to say.

I suspect it is like C++ and C. If there is both, you promote up to C++ linking.
So if there is any .swift file or library in the mix, you need to
promote up to use Swift.

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

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

I then added to my test CMakeLists.txt:
set_property(TARGET MyApp PROPERTY LINKER_LANGUAGE Swift)

That then worked, but I'm confused how to get CMake to automatically
do this for me because I expected CMAKE_Swift_LINKER_PREFERENCE to do
this.


>
> This looks like a semantic difference between how the switfc and cc
> compilers work that as I feared in my previous response may require
> C++ changes to CMake to make work.  Before diving into that we need
> to understand the preferred way to compile multiple Swift sources.
> Last time I looked at this the only reference was "what Xcode does".
> Hopefully there is more information out there now.

Unfortunately, there isn't a whole lot more information. The majority
of the examples are hello world programs with one file.

The best write up I've seen is this series:
http://owensd.io/blog/compiling-swift-without-xcode/
http://owensd.io/blog/compiling-individual-files/
http://owensd.io/blog/swift-vs-swiftc/
http://owensd.io/blog/swift-makefiles---take-2/

One interesting note, swiftc is just an alias for swift.


The exception is the Swift Package manager. But this is a convention
based system. Right now it is far from finished and its conventions
are actually incompatible with Xcode. It has its own file format and
also requires all dependency packages be in a Git repo and follow a
certain tagging convention. I also haven't seen any way to directly
mix C+Swift code in a module and they expect you to create a separate
module for C stuff which you then import in. I'm under the impression
they plan to relax a lot of these things, but I find it currently too
incomplete and with too much impedance to be useful right now.

(By the way, I think I'm a little incorrect about main.swift being
special. I'm seeing examples where they name the file anything.swift.
It looks like Swift will automatically create a main entry point for
you when building an executable, especially in the one-shot case. With
swiftc it must be a one-shot otherwise you get duplicate symbols. With
swift -frontend, it some how manages to create one. But with the Swift
Package system, I think main.swift is a convention-requirement.)



> It may be that we're supposed to invoke Swift with all sources at once
> and let it take responsibility for generating the results and doing any
> kind of incremental stuff internally.

So Xcode is using the swift -frontend technique and it looks like it
doing it incrementally. I think the requirement for the list of other
files is so it can resolve the dependencies.


> It shouldn't be too hard to add a  placeholder if needed.  We
> may need it either way because we either list all the sources on one
> call to swift or on every call to swift.

Right.

>> - Also, for the second , I need to remove the one I'm using
>> from my -primary-file. And there shouldn't be any non-Swift files in
>> the list (no C/C++/Obj-C).
>
> That kind of filtering may be harder to define and require custom logic
> in CMake's generators for Swift instead of trying to do it with generic
> placeholders.

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.
However, we do need to filter any C files. That didn't work. (It tried
to compile those .c files as Swift which obviously won't work.)



>> Can you give me some suggestions on what to look at next?
>
> Before proceeding with CMake changes I think we need a better
> understanding of the tools involved in Swift development.  What
> does individual compilation achieve over monolithic compilation?

I'm actually not sure. The monolithic one-shot should avoid any
potential incorrectness problems if a dependent file was changed but a
calling file wasn't recompiled. I don't 

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

[Brad King]

On 01/08/2016 06:15 PM, Eric Wing wrote:
> simple 'swiftc' integration going for ADD_EXECUTABLE, as described in
> the original post.

Take the generator check out of Modules/CMakeDetermineSwiftCompiler.cmake
to get rid of the up-front error.  See "Modules/CMakeAddNewLanguage.txt"
(many of the steps are already done).

Edit Modules/CMakeSwiftInformation.cmake and add settings for variables
like CMAKE_Swift_COMPILE_OBJECT and CMAKE_Swift_LINK_EXECUTABLE.  See
the CMake{C,CXX,Fortran}Information.cmake modules for examples.  The
available placeholders are in cmLocalGenerator::ExpandRuleVariable.

If all the compile/link steps used for C and C++ map well to switfc
then it should be fairly straightforward.  If other steps are needed
or the steps have wildly different semantics then more in-depth changes
to the actual generators may be needed.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [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
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Brad King]

On 12/24/2015 06:13 AM, Eric Wing wrote:
> Now that Swift is officially open source and already available for
> Linux, I started looking at the build process on Linux which I hope we
> can figure out how to incorporate into the CMake Makefile generator.

Thanks for digging in to this!

> To start with, there actually seem to be two different approaches.
> 1) The swiftc command line compiler (similar to gcc, clang with
> switches and output that seem to resemble them as well)
> 2) A formal package/module system for Swift which works with a Swift
> command line build tool ‘swift build’
> 
> So far, for my usage cases, I’ve found the (2) package/module system
> to be annoying and a bunch of indirection and extra steps. I also
> don’t feel I have completely wrapped my head around it, so I’m not
> going to focus on this for now. However, as more pure Swift libraries
> get written, I think interoperating with the module system will become
> extremely important, which we’ll ultimately need to deal with.

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.

Swift does have conditional compilation that affects imports.

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.



> But in the meantime, back to (1) swiftc, this I found much more
> straight-forward, at least for dealing with C code and C libraries and
> I think maps pretty well to the current CMake design.

Great.

> There is a pretty good example/write up found here:
> http://dev.iachieved.it/iachievedit/more-swift-on-linux/

Good link.

> For a Swift application that also has C code, and uses C libraries,
> this is the basic procedure:
> 
> 1) Compile the C files into .o
> clang -c escapetext.c
> 
> 2) Compile the Swift files into .o (note: The header seems to be the
> ‘Bridging Header’ discussed in the prior thread)
> swiftc -c escapeswift.swift -import-objc-header escapetext.h
> 
> 3) Link all the object files together to build the final app executable
> swiftc escapeswift.o escapetext.o -o escapeswift -lcurl

Okay.

> (Note: ‘main.swift’ seems get
> special handling by the swift compiler and is always treated as your
> application entry point.)

Yes, that seems to be the case.  Furthermore the file can just have
code directly in the top level because the whole thing is the "main"
function.

> So I’d like to talk about how to further enhance CMake to do the above.

Okay.  Ideally I'd like a solution designed with understanding of the
module system as mentioned in my notes above.

> In my head, for the above examples, I think I would want to do
> something like:
> 
> find_package(SDL)
> include_directories(${SDL_INCLUDE_DIR})
> 
> # Forgot if we already had a convention for controlling this in the
> Xcode generator
> set(SWIFT_BRIDGING_HEADER SwiftSDL-Bridging-Header.h)

As you noted in another response, we have a per-target property
XCODE_ATTRIBUTE_SWIFT_OBJC_BRIDGING_HEADER.  The bridging header
does need to be per-target, yes.

> add_executable(MyAppExe
>   SDLSwiftBinding.c
>   main.swift
>   MyApp.swift
> )
> target_link_libraries(MyAppExe ${SDL_LIBRARY})

Yes, that looks like what we want to achieve.

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: 

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

[Eric Wing]

On 12/24/15, Eric Wing  wrote:
>> set(SWIFT_BRIDGING_HEADER SwiftSDL-Bridging-Header.h)
>
> Quick addendum: Just realized the bridging header should probably be
> per-target.
>

For reference, we have an Xcode specific, per-target variable for the
bridging header: XCODE_ATTRIBUTE_SWIFT_OBJC_BRIDGING_HEADER.

set_property(TARGET ${BLURRR_USER_EXECUTABLE_NAME} PROPERTY
XCODE_ATTRIBUTE_SWIFT_OBJC_BRIDGING_HEADER
"${PROJECT_SOURCE_DIR}/source/MySwiftBridgingHeader.h")
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

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

[Eric Wing]

> set(SWIFT_BRIDGING_HEADER SwiftSDL-Bridging-Header.h)

Quick addendum: Just realized the bridging header should probably be per-target.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Swift support to CMake

[Gregor Jasny via cmake-developers]

Hi Eric  Brad,

On 15/07/15 12:16, Eric Wing wrote:
 On 7/7/15, Brad King brad.k...@kitware.com wrote:
 On 07/02/2015 07:54 PM, Eric Wing wrote:
 Thank you Brad. When you are ready, let me know how I can help next.

 I have basic support with the Xcode generator done.

 Please try out this commit:

  Add rudimentary support for the Apple Swift language with Xcode
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531

I was just digging through OSX 10.11 / Xcode 7 errors and noticed that
the Swift tests fail with Xcode7:

https://open.cdash.org/buildSummary.php?buildid=3972344

 CompileSwift normal x86_64 
 /Users/builder/external/CMake/Tests/SwiftOnly/main.swift
 cd /Users/builder/external/CMake/Tests/SwiftOnly
 
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift
  -frontend -c -primary-file 
 /Users/builder/external/CMake/Tests/SwiftOnly/main.swift -target 
 x86_64-apple-macosx10.11 -enable-objc-interop -sdk 
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
  -I /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/Debug -F 
 /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/Debug 
 -serialize-debugging-options -Xcc 
 -I/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/swift-overrides.hmap
  -Xcc 
 -I/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/Debug/include
  -Xcc 
 -I/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/DerivedSources/x86_64
  -Xcc 
 -I/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/DerivedSources
  -Xcc -DCMAKE_INT
 D
IR=\Debug\ -Xcc 
-working-directory/Users/builder/external/CMake/Tests/SwiftOnly 
-emit-module-doc-path 
/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main~partial.swiftdoc
 -O -module-name SwiftOnly -emit-module-path 
/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main~partial.swiftmodule
 -serialize-diagnostics-path 
/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main.dia
 -emit-dependencies-path 
/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main.d
 -emit-reference-dependencies-path 
/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/SwiftOnly.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main.swiftdeps
 -o /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/SwiftOnly/Swif
 t
Only.build/Debug/SwiftOnly.build/Objects-normal/x86_64/main.o
 /Users/builder/external/CMake/Tests/SwiftOnly/main.swift:1:1: error: 
 'println' has been renamed to 'print'
 println(SwiftOnly)
 ^~~
 print
 Swift.println:1:82: note: 'println' has been explicitly marked unavailable 
 here
 @available(*, unavailable) @inline(never) @_semantics(stdlib_binary_only) 
 func printlnT(value: T)

Thanks,
Gregor
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Swift support to CMake

[Eric Wing]

On 7/7/15, Brad King brad.k...@kitware.com wrote:
 On 07/02/2015 07:54 PM, Eric Wing wrote:
 Thank you Brad. When you are ready, let me know how I can help next.

 I have basic support with the Xcode generator done.

 Please try out this commit:

  Add rudimentary support for the Apple Swift language with Xcode
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531

 Thanks,
 -Brad



Hi Brad,
I just tried out the July 15th nightly build and it looks like it is
working (Xcode generator). I got a little fancy and did an intermixed
C/Swift test. I have a simple SDL (C) based program with Swift
bindings and I'm able to build/run it and step the Xcode debugger
through the Swift parts.

Cosmetically, the Swift files are not being grouped with the other
C/Obj-C files in the Source Files group. But that is a pretty minor
thing. (There are other things more important to me I would like to
see fixed in the Xcode generator first :))

So is the next step the Makefile generator?

Thanks,
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Swift support to CMake

[Brad King]

On 07/15/2015 06:16 AM, Eric Wing wrote:
 I just tried out the July 15th nightly build and it looks like it is
 working (Xcode generator). I got a little fancy and did an intermixed
 C/Swift test. I have a simple SDL (C) based program with Swift
 bindings and I'm able to build/run it and step the Xcode debugger
 through the Swift parts.

Great, thanks for testing.

 So is the next step the Makefile generator?

The Makefile and Ninja generators should be done together.  I recently
refactored things to help them share more infrastructure.  The hard part
is figuring out what command lines actually need to be invoked.  There
is no documentation from Apple for this AFAIK so someone will have to
figure it out based on what Xcode does.

I have no time to work on any of this myself.  My goal with getting it
working in Xcode was just to do the minimum needed to get the basic
language module infrastructure in place within CMake.  Others will have
to take over from there.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Swift support to CMake

[Stephen Kelly]

Brad King wrote:

 On 07/02/2015 07:54 PM, Eric Wing wrote:
 Thank you Brad. When you are ready, let me know how I can help next.
 
 I have basic support with the Xcode generator done.
 
 Please try out this commit:
 
  Add rudimentary support for the Apple Swift language with Xcode
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bf112531

Since Apple is the only vendor implementing the language
right now, the compiler id can be just `Apple`.

This seems somehow wrong. Naming it based on some state 'right now' doesn't 
seem future proof. The 'MSVC' compiler id is not called 'Microsoft', the 
'QCC' compiler id is not called 'QNX', 'XL' is not called 'IBM'.

Is there a better name?

Thanks,

Steve.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Swift support to CMake

[Brad King]

On 07/08/2015 02:35 PM, Stephen Kelly wrote:
 Since Apple is the only vendor implementing the language
 right now, the compiler id can be just `Apple`.

Even if another vendor implements it the one we're identifying
will still be provided by Apple.  The above wording was poor.

 This seems somehow wrong. Naming it based on some state 'right now' doesn't 
 seem future proof. The 'MSVC' compiler id is not called 'Microsoft', the 
 'QCC' compiler id is not called 'QNX', 'XL' is not called 'IBM'.

The PGI compiler id is PGI.  The PathScale compiler id is PathScale.
The TI compiler id is TI.  The GNU compiler id is GNU.  The Cray
compiler id is Cray.  The Absoft compiler id is Absoft.  There is
plenty of precedent to use the vendor name.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Swift support to CMake

[Stephen Kelly]

Brad King wrote:

 This seems somehow wrong. Naming it based on some state 'right now'
 doesn't seem future proof. The 'MSVC' compiler id is not called
 'Microsoft', the 'QCC' compiler id is not called 'QNX', 'XL' is not
 called 'IBM'.
 
 The PGI compiler id is PGI.  The PathScale compiler id is PathScale.
 The TI compiler id is TI.  The GNU compiler id is GNU.  The Cray
 compiler id is Cray.  The Absoft compiler id is Absoft.  There is
 plenty of precedent to use the vendor name.

I guess. I think part of the reason it seems wrong to me is that there is a 
platform id called 'APPLE' (different case) and a variable of that name

There is also an existing GNU platorm/compiler id (same case).

If the same name is to be used, is there any reason not to use the same 
case?

Thanks,

Steve.


-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Swift support to CMake

[Brad King]

On 07/08/2015 03:04 PM, Stephen Kelly wrote:
 I guess. I think part of the reason it seems wrong to me is that there is a 
 platform id called 'APPLE' (different case) and a variable of that name
 
 There is also an existing GNU platorm/compiler id (same case).
 
 If the same name is to be used, is there any reason not to use the same 
 case?

All compiler id values use CamelCase or are acronyms.  The variable
named APPLE is historical and meant to match the __APPLE__
preprocessor macro.  Compiler id values are different.

What do you think of Ben's AppleSwift suggestion?

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Swift support to CMake

[Eric Wing]

On 6/29/15, Brad King brad.k...@kitware.com wrote:
 On 06/25/2015 09:24 AM, Eric Wing wrote:
 I pushed up a couple of repos for everybody to try.

 Thanks.  From that I was able to make some progress with getting
 CMakeDetermineSwiftCompiler to work.

 I've made two tweaks to CMakeDetermineCompilerId to make it easier to
 use from a new CMakeDetermineSwiftCompiler module:

  CMakeDetermineCompilerId: Simplify src reference in IDE projects
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8306108f

  CMakeDetermineCompilerId: Use per-language regex to match Xcode compiler
 tool
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6452291c

 Once these changes test cleanly on nightly builds I will look at
 the rest of the changes for basic Swift + Xcode.

 -Brad


Thank you Brad. When you are ready, let me know how I can help next.

Thanks,
Eric
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Swift support to CMake

[Brad King]

On 06/25/2015 09:24 AM, Eric Wing wrote:
 I pushed up a couple of repos for everybody to try.

Thanks.  From that I was able to make some progress with getting
CMakeDetermineSwiftCompiler to work.

I've made two tweaks to CMakeDetermineCompilerId to make it easier to
use from a new CMakeDetermineSwiftCompiler module:

 CMakeDetermineCompilerId: Simplify src reference in IDE projects
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8306108f

 CMakeDetermineCompilerId: Use per-language regex to match Xcode compiler tool
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6452291c

Once these changes test cleanly on nightly builds I will look at
the rest of the changes for basic Swift + Xcode.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Adding Swift support to CMake

[Eric Wing]

Hi Brad,
I pushed up a couple of repos for everybody to try.

First, I have my CMake changes I mentioned before. There are 2
commits. The first commit is the original simple hack. The second
commit removes the hack part and tries to add a new language generator
for Swift, using Java as a starting point. I think both of these work
for the simple case right below.
The branch is called Swift
https://github.com/ewmailing/CMake/tree/Swift

Second, I have a simple, but comprehensive test/example based project
for C calling Swift (which must go through Objective-C), and then once
in Swift, calling C. I refer to this as the full round trip example.
I have two projects, one from a native Xcode project, and another in
CMake with my above CMake patches.

https://github.com/ewmailing/CSwiftRoundTripNativeXcode
https://github.com/ewmailing/SwiftXcodeCMake



 Let's start by getting that to work for the Xcode generator.  Currently
 Modules/CompilerId/Xcode-3.pbxproj.in gets configured by the
 CMAKE_DETERMINE_COMPILER_ID_BUILD function as a small test project
 to compile the C or C++ source for compiler identification.  From
 the output of that build we are able to extract the path to the
 compiler tool.  One would have to do something similar here.  Can
 you provide a minimal pbxproj file and swift source file that
 work together to build an executable?

Okay, I just went through the Xcode New Project wizard and created a
new default Swift project for Cocoa and command line tool (both OS X).
https://github.com/ewmailing/SwiftMinimal
https://github.com/ewmailing/SwiftMinimalCL




 What is the proper sequence of commands to build some C and Swift
 sources and link a single executable?  library?


Here is a minimal Swift executable project created in Xcode that calls
a C function. (One way bridge.)
https://github.com/ewmailing/SwiftAndC

Build target SwiftAndC

CompileSwiftSources normal x86_64 com.apple.xcode.tools.swift.compiler
cd /Volumes/DataPartition/Users/ewing/Source/GIT/SwiftAndC

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc
-target x86_64-apple-macosx10.10 -incremental -module-name SwiftAndC
-Onone -sdk 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk
-g -module-cache-path
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/ModuleCache
-Xfrontend -serialize-debugging-options -I
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Products/Debug
-F 
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Products/Debug
-c -j4 
/Volumes/DataPartition/Users/ewing/Source/GIT/SwiftAndC/SwiftAndC/main.swift
-output-file-map
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/Objects-normal/x86_64/SwiftAndC-OutputFileMap.json
-parseable-output -serialize-diagnostics -emit-dependencies
-emit-module -emit-module-path
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/Objects-normal/x86_64/SwiftAndC.swiftmodule
-Xcc 
-I/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/swift-overrides.hmap
-Xcc -iquote -Xcc
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/SwiftAndC-generated-files.hmap
-Xcc 
-I/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/SwiftAndC-own-target-headers.hmap
-Xcc 
-I/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/SwiftAndC-all-target-headers.hmap
-Xcc -iquote -Xcc
/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/SwiftAndC-project-headers.hmap
-Xcc 
-I/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Products/Debug/include
-Xcc 
-I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
-Xcc 
-I/Volumes/DataPartition/Users/ewing/Library/Developer/Xcode/DerivedData/SwiftAndC-fxaehuxdwmjlsabccqgmmadmslyz/Build/Intermediates/SwiftAndC.build/Debug/SwiftAndC.build/DerivedSources/x86_64
-Xcc 

Re: [cmake-developers] Adding Swift support to CMake

[Brad King]

On 06/17/2015 05:52 AM, Eric Wing wrote:
 To meet these objectives, I see two things we need to do:
 - For the first and simplest case, we need to enhance the CMake Xcode
 generator so it can handle Swift. Xcode already knows how to handle
 Swift files automatically, so we should leverage it by making CMake
 generate a correct project for it.

Let's start with Xcode and make enabling the language an error for
other generators at first.

 GetSourcecodeValueFromFileExtension(), I added swift right after the
 Obj-C entries.
 
   else if (ext == swift)
 {
 sourcecode += .swift;
 }

Good.

 set(CMAKE_C_SOURCE_FILE_EXTENSIONS c;m;swift)
 
 This works pretty well for my initial test case which is a mixture of
 C/Obj-C/Swift. But I was told we should be looking at building a
 separate language generator instead of this latter hack.

Right.  There have been efforts here in the past to make separate
OBJC and OBJCXX languages too.  Using the C and CXX languages for
those has always been a partial solution.  For Swift we should do it
right the first time.

   CMakeDetermineSwiftCompiler.cmake

Let's start by getting that to work for the Xcode generator.  Currently
Modules/CompilerId/Xcode-3.pbxproj.in gets configured by the
CMAKE_DETERMINE_COMPILER_ID_BUILD function as a small test project
to compile the C or C++ source for compiler identification.  From
the output of that build we are able to extract the path to the
compiler tool.  One would have to do something similar here.  Can
you provide a minimal pbxproj file and swift source file that
work together to build an executable?

 - However, since Swift is designed to operate with C and Obj-C, there
 does seem to be a mechanism to create files that can be linked with
 C/Obj-C (needed by the Makefile generator; should be automatic by
 Xcode)

What is the proper sequence of commands to build some C and Swift
sources and link a single executable?  library?

Thanks,
-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Adding Swift support to CMake

[Eric Wing]

Hello all,
I wanted to see if I could get the ball rolling on (Apple) Swift
support for CMake.

For more detail, here is the bug I’ve been chatting in:
http://public.kitware.com/Bug/view.php?id=15401

Here is the summary:
- For Apple developers, we need Swift support because it is going to
be increasingly common to have Swift files in the project, often as
backends for the Apple platform specific stuff in cross-platform
projects, just as Objective-C is today.

- Coming this fall, Swift is going to be open sourced, starting with a
Linux port. So we may start seeing more use cases on non-Apple
platforms as well.


To meet these objectives, I see two things we need to do:
- For the first and simplest case, we need to enhance the CMake Xcode
generator so it can handle Swift. Xcode already knows how to handle
Swift files automatically, so we should leverage it by making CMake
generate a correct project for it.

- The next step is to look at the Makefile generator and command line
invocation. With luck, this will work for Mac, Linux, and probably any
other Unix-like platform that gets Swift/LLVM running.


As a first stab to get Xcode support working,
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)


This works pretty well for my initial test case which is a mixture of
C/Obj-C/Swift. But I was told we should be looking at building a
separate language generator instead of this latter hack.



So this is where I’m starting to get lost/overwhelmed, and am hoping
to find other people that might be able to help make this happen.

At the moment, I created 4 new files:
CMakeDetermineSwiftCompiler.cmake
CMakeSwiftCompiler.cmake.in
CMakeSwiftInformation.cmake
CMakeTestSwiftCompiler.cmake

I originally started with C as the template and got lost quickly. I
have since started using Java as the template and have muddled through
a little bit more. In my current Xcode prototype, I’ve been fighting
various flags, e.g. my C flags getting clobbered by Swift, when in
fact I need both. (e.g. lost my @rpath/@loader_path stuff.)

So, I’m still lacking a lot of knowledge on both the CMake side (how
to implement a new language), and also a lot of the reverse
engineering details of how Swift works. Maybe we can layout the
details in this thread.

These are the various details that I’m aware of at the moment:

- The swift compiler is called swiftc

- Swift doesn’t really have a preprocessor or linker in the traditional C sense.

- However, since Swift is designed to operate with C and Obj-C, there
does seem to be a mechanism to create files that can be linked with
C/Obj-C (needed by the Makefile generator; should be automatic by
Xcode)

- I don’t think Swift needs dependency management like in Makefiles
and swift handles everything for you transparently (ignoring
intermixing with C/Obj-C). However, you still need a build system to
handle other things like asset files (images, icons, etc.)

- Swift projects generally need to provide a “bridging header” to be
able to call C/Obj-C code

- Swift projects need a generated Interface Header so C/Obj-C can call
Swift code

- Swift has its own optimization flag settings separate from C/Obj-C

- Swift seems to have its own ‘other flags’

- I think there is a way to build Swift-only modules, but I have not
looked into this. Intermixing C/Obj-C probably means you can fall back
to the clang mechanisms.

- On OSX/iOS, it would be nice to make Swift automatically enabled
since it is kind of a required language now. (Requiring
ENABLE_LANGAUGE(Swift) seems annoying.)

- I’m kind of assuming, but don’t really know, that Obj-C and the
Obj-C runtime will be available with the Linux port of Swift, and that
you will generally want it and might even be required. (Note: I am
being careful to distinguish between Obj-C and libraries like
Foundation.) Being able to call Swift from C requires Obj-C (in my
limited experience). Swift’s easy interoperability with C (in both
directions) I think is a selling point for Swift and expect it to be
used, particularly on Linux where C is prevalent. So I think we need
to make sure this intermixing can be handled by the Makefile
generator.

- Here is the best resource I've found so far on building a Makefile for Swift:
http://owensd.io/2015/01/15/swift-makefiles-take-2.html


So anybody who wants to chime in, please do so!
Let's see if we can make this happen.