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
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
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
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
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
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
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
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
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
(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
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
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
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
> 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
>> 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
>
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
> 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,
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
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:
> 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
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:
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
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
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
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
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
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,
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
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
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
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
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
32 matches
Mail list logo