[cmake-developers] Test for compiler flags ineffective with xlc?
Hi,
In this build log the test for -fvisibility=hidden results in success, but
when the flag is used it fails:
http://www.cdash.org/CDash/testDetails.php?test=109109951build=1419259
I'm guessing that compiler treats -ffoo as a filename for some reason. Can
anything be done about that? Should I just exclude that platform from
performing the test? How? Would if (${CMAKE_CXX_COMPILER_ID} MATCHES xlC)
match?
Thanks,
Steve.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting environment variables for builds
On Monday 08 August 2011, Brad King wrote: On 8/8/2011 4:24 AM, Johan Björk wrote: This has been discussed a billion times, so I'll keep it short. Problem: Some parts of the build requires a environment variable to be set Solution: Several workarounds, use custom commands, wrapper scripts etc. While the solution works fine for basic stuff, I have several toolchains etc that requires environment variables to be installed for them to work. CMake has always assumed that the environment is setup correctly for the desired toolchain before either cmake or make runs. Typically developers have dealt with this by naming the build tree after the toolchain needed as a reminder of the environment needed. I'm sure an alternative would be welcomed by many. Since I'm using cmake --build for all my building, I am thinking about creating a new command in cmake that will store certain environment variables in the cache, and if building using cmake --build, they will be set before the build starts. This sounds like a great compromise. I don't think the cache is the right place to put this though. I think you can create your own file like CMakeFiles/cmake--build.env and give it a format customized for this purpose (like one line per variable or something). In the Eclipse project generator, I do something similar. Depending on the used compiler, a set of env.variables are stored in the cache and written into the project file, so they will be set when Eclipse invokes make. E.g. for the Intel compiler that's the license-related one, for MSVC it's LIBDIR or something like this. Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Test for compiler flags ineffective with xlc?
Hi Stephen :-)
On Thursday 11 August 2011, Stephen Kelly wrote:
Hi,
In this build log the test for -fvisibility=hidden results in success, but
when the flag is used it fails:
http://www.cdash.org/CDash/testDetails.php?test=109109951build=1419259
I'm guessing that compiler treats -ffoo as a filename for some reason.
Can anything be done about that? Should I just exclude that platform from
performing the test? How?
Would if (${CMAKE_CXX_COMPILER_ID} MATCHES xlC) match?
Should be XL, see Modules/CMakeCCompilerId.c.in, there they are all defined.
You can also see this here in the output from the cmake run:
http://www.cdash.org/CDash/viewConfigure.php?buildid=1419259
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting environment variables for builds
On Thu, Aug 11, 2011 at 3:51 PM, Alexander Neundorf neund...@kde.orgwrote:
On Monday 08 August 2011, Brad King wrote:
On 8/8/2011 4:24 AM, Johan Björk wrote:
This has been discussed a billion times, so I'll keep it short.
Problem: Some parts of the build requires a environment variable to be
set Solution: Several workarounds, use custom commands, wrapper scripts
etc.
While the solution works fine for basic stuff, I have several
toolchains
etc that requires environment variables to be installed for them to
work.
CMake has always assumed that the environment is setup correctly for the
desired toolchain before either cmake or make runs. Typically developers
have dealt with this by naming the build tree after the toolchain needed
as a reminder of the environment needed. I'm sure an alternative would
be welcomed by many.
Since I'm using cmake --build for all my building, I am thinking about
creating a new command in cmake that will store certain environment
variables in the cache, and if building using cmake --build, they will
be set before the build starts.
This sounds like a great compromise. I don't think the cache is the
right place to put this though. I think you can create your own file
like CMakeFiles/cmake--build.env and give it a format customized for
this purpose (like one line per variable or something).
In the Eclipse project generator, I do something similar.
Depending on the used compiler, a set of env.variables are stored in the
cache
and written into the project file, so they will be set when Eclipse invokes
make.
E.g. for the Intel compiler that's the license-related one, for MSVC it's
LIBDIR or something like this.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
You could have a --with-env env.cmake for the --build stuff.
And in the env.cmake file, you could simply have commands of the form:
set(ENV{abc} abc val)
set(ENV{xyz} xyz val)
As long as the script is processed in the same CMake process that runs the
--build, the environment settings should stick around for the duration of
the build.
Of course, there's not an easy, existing way to prevent other non-env
commands from being executed in such a script. This may or may not be deemed
a good idea, but I figured I had to throw it out there: rather than
inventing a whole new way of expressing environment variables in a file,
let's use some existing mechanism...
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
