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
20 matches
Mail list logo