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
