On 2/4/16, Brad King <brad.k...@kitware.com> 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
