When using `cmake ... -DCMAKE_C_COMPILER=gcc;-pipe` first invocation of
CMake worked correctly.
When using `cmake ... -DCMAKE_C_COMPILER=/path/to/gcc;-pipe` first
invocation of CMake detected a change to CMAKE_C_COMPILER, printed "You
have changed variables" message, and re-ran the initial compiler tests
after configuration was complete and before generation of the project
files.
The difference was due to the cache being forced updated with the new
value of CMAKE_C_COMPILER so that the comparison check passes.
Capture CMAKE_<LANG>_COMPILER_ARG1 from CMAKE_<LANG>_COMPILER in the
same fashion that it is from $ENV{<LANG>}.
Since get_filename_component() returns a single string of all the
arguments from $ENV{<LANG>}, a single string of arguments will be
constructed from the items contained in CMAKE_<LANG>_COMPILER.
Fixes#20089
7f786c6a40 Tests: Cover CheckTypeSize with uint8_t and std::uint8_t
371072e9e1 CheckTypeSize: Use C++-style headers to check for std:: types
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5008
Since commit 9b97cb5562 (PGI: Add language standards for PGI,
2017-05-01, v3.9.0-rc1~174^2), we have passed the `-A` flag to
the PGI C++ compiler when specifying a C++ standard flag with
compiler extensions turned off. The flag is not meant for that.
The PGI C++ standard flags do not turn extensions on by default
and have a separate `--gnu_extensions` flag for that which we
already use when CXX_EXTENSIONS is ON. Simply drop the `-A` flag.
Fixes: #20997
When `CMAKE_OSX_ARCHITECTURES` is not specified, we add the Xcode
setting `ONLY_ACTIVE_ARCH = YES` with the intention of targeting the
native architecture of the host. However, the default `ARCHS` value
chosen by "Xcode 12 Universal Apps" includes multiple architectures.
Add an explicit `ARCHS` setting with value `$(NATIVE_ARCH_ACTUAL)`
to tell Xcode to use the host's native architecture only.
Fixes: #20893
Explain the purpose of this variable and the conditions under which
it can be set. Point out that it should not be set explicitly without
also setting `CMAKE_CUDA_COMPILER` explicitly.
Issue: #20826
The object and library files have to be listed after the `--run-linker`
flag.
But after this flag the `--cmd_file` flag for response files cannot be
used any more.
Putting the whole command line into a response file would work, but
this is not supported by CMake (yet).
By adding the compiler flags via `<FLAGS>` to the linker call,
the linker can decide which default library to use.
CMake replaces `<FLAGS>` by the content of `CMAKE_<LANG>_FLAGS`.
So any relevant flag needs to be defined in this variable, preferably
in a toolchain file.
The compiler flags have to be specified before the `--run_linker`
flag and the linker flags afterwards.
Replaces Merge-request !4890
The path to the 32 bit libraries in the Intel windows/redist folder use
ia32. I don't remember if this has changed at some point, but ia32 has
been used at least since Intel Fortran XE 2018.
The version is determined in two steps. First, the "spec date" is
detected and cached. Second, the date is converted to a version.
Move the second step out of the spec date cache guard condition
so that it runs every time even if the spec date is already cached.
Fixes: #19150
Since commit dd378258f1 (FindJava: Do not accept OS X stub 'java' as
Java, 2014-10-24, v3.1.0-rc3~29^2) we try to avoid using the macOS
`/usr/bin/java` stub if no underlying implementation of Java is actually
installed. However, the message that `/usr/bin/java` prints when there
is no Java available has changed since then. Update our check to also
look for the new message.
While at it, revise the way we suppress `Java_JAVA_EXECUTABLE`.
Previously we set its cache entry to `Java_JAVA_EXECUTABLE-NOTFOUND`,
but that would cause the same find-and-reject sequence to be followed
every time CMake runs in a build tree. Instead, use the approach from
commit 2c0db404d1 (FindSubversion: Do not accept macOS stub without
Xcode implementation, 2020-05-28, v3.18.0-rc1~67^2). Leave the cache
entry alone and just set a normal variable of the same name to hide it.
An "unknown" version does not always mean an old version. Setting this
macro by mistake does not result in a compilation error, but not setting
it does. I had this error when compiling from a user that does not have
a matlab license.
Fred Baksik