The macro is defined to 1 for GNU 4.6, and such a test is only
useful for features in language dialects newer than the
default (CXX98 for GNU currently).
Test only that it has a truthy value.
As this is not elseif(), the content has no effect.
Rather than changing it to an elseif(), remove the conditional content.
All versions of GNU prior to 5.0 default to C90/89.
Clang-C.cmake has a similar code block which correctly uses
elseif() for setting the default C dialect to C99. That may have
been updated from a C90 default at some point, so leave the
version condition there in place for now.
GNU-CXX already has complex logic and sets the _result to 0 before
tests which may set it to something else.
Change the other modules to be consistent with that.
Add support for a special URL template to map the fetch operation
to a project-specified .cmake script insead of using file(DOWNLOAD).
Extend the Module.ExternalData test to cover the behavior.
Extend the RunCMake.ExternalData test to cover error cases.
Move the basic DATA{} description to a section just before the
file series description. Move all sections on referencing files
into subsections of a common "Referencing Files" section.
Subsume example usage into the introduction since it gives a
high-level starting point to understand the rest of the docs.
da928d30 Help: Add notes for topic 'Apple-compiler-selection'
1f085e11 OS X: Resolve compiler in /usr/bin to that reported by Xcode xcrun
85d31735 CMakeDetermineCompiler: Factor out xcrun invocation into a macro
dcd72a74 Help: Add notes for topic 'Xcode-clang-compile-features'
3ad893b5 Features: Record for historical Xcode clang versions.
98965fb1 Features: Record dialect flags for AppleClang 4.0+.
The compiler in the PATH on mac is a stub for a different delegate
depending on the environment. Rather than requiring xcode-select to
change the used Xcode globally, users should be able to choose the
compiler per-session. That is possible with the DEVELOPER_DIR
environment variable.
However, the environment can change between running CMake and invoking
the build. In such cases, CMake prefers to record the relevant paths
from the environment and use them when invoking the build. That is not
currently done for the compilers on APPLE, so the compiler used is not
the one reported when running cmake:
$ DEVELOPER_DIR=/Applications/Xcode2.app/Contents/Developer/ cc --version
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
$ DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer/ cc --version
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
Update that now by querying Xcode for the correct compiler path if
the compiler located by ordinary means is located in /usr/bin.
Revert commits:
2d738ce3 Help: Add notes for topic 'feature_record_msvc'
f73718c9 Features: Enable writing of MSVC compiler feature header.
64c30bdc Features: Record for MSVC C++ 2015 and MSVC C 2010-2015.
225c0ef8 Features: Record for MSVC 2010-2013.
This topic was merged to master prematurely, so remove it.
In commit v3.1.0-rc1~113^2 (Use a more reliable regex for extracting
binary INFO strings, 2014-09-03) the matching of INFO: strings was made
more strict and no longer matches just "INFO:qnxnto". Use
"INFO:qnxnto[]" instead to conform to the new pattern.
When installing, MSMPI puts a trailing backslash in the MSMPI_BIN
environment variable. This causes trouble when concatenating in CMake
since the list separator is now escaped and no longer a list separator
due to the trailing backslash. Instead, use file(TO_CMAKE_PATH) to make
the path CMake-friendly.
The approach in commit v3.1.0-rc1~1^2 (Xcode: Fix compiler id detection
when code signing is required, 2014-10-22) still requires a code signing
key when targeting a real device. Instead set CODE_SIGNING_REQUIRED to
"NO" to tell Xcode not to sign at all. Drop the corresponding setting
of the code signing identity.
Since commit v2.8.8~173^2 (FindRuby: clean up querying variables from
Ruby, 2012-02-17) we query RbConfig::CONFIG first and, if the command
fails or its output equates to a false constant, then fall back to
querying Config::CONFIG.
Due to the above, an error condition exists with Ruby 2.2.0; when
querying RbConfig::CONFIG['TEENY'], the output of '0' will be discarded
since it matches the false constant '0'.
In previous versions this wasn't a problem, but Ruby 2.2 has completely
removed Config::CONFIG. This causes RUBY_VERSION_PATCH to be set to an
empty string and the Ruby version to be detected as '2.2.' (instead of
'2.2.0').
Fix the output check to explicitly look for an empty string before using
the fallback query method. (Someone more familiar with Ruby might be
able to deem the fallback as unnecessary and fully remove it.)
2d738ce3 Help: Add notes for topic 'feature_record_msvc'
f73718c9 Features: Enable writing of MSVC compiler feature header.
64c30bdc Features: Record for MSVC C++ 2015 and MSVC C 2010-2015.
225c0ef8 Features: Record for MSVC 2010-2013.
Notes:
VS2015 and above are the only MSVC versions to support cxx_final, so remove
usages from the tests, and instead only test for cxx_override.
VS2012 and above to conform to cxx_decltype_incomplete_return_types
proposal, but without support for auto return types the dcl.type.simple
example in the proposal doesn't compile.
VS2013 and above to conform to the updated cxx_contextual_conversions proposal,
but VS2010 and above pass the test.
Compilers such as MSVC have no explicit flags to enable C++11 mode,
it just is always on. So only run the link tests with compilers that require
a flag to specify the language version.
Initializer lists are only properly supported in 2015 and above.
Previous Visual Studio releases said they supported initializer lists
but silently produced bad code.
CMAKE_SYSTEM_PROCESSOR is not guaranteed to be defined (per
http://www.cmake.org/Wiki/CMake_Cross_Compiling), and when cross
compiling where it happens to be undefined, this module was broken.
Reviewed-by: Rolf Eike Beer <eike@sf-mail.de>
Previously only the CMAKE_{C,CXX}_FLAGS_<CONFIG> flags were inspected
for relevant flags when compiling the intermediate link file. We need
to also consider the configuration agnostic flags, CMAKE_{C,CXX}_FLAGS
as well.
AppleClang does not support the cxx_thread_local feature, even
though it is based on a Clang version which does support the
feature.
http://stackoverflow.com/a/23850891/2428389
A possible reason for that is that thread_local might be used as
a variable in existing Apple SDK headers.
Extend the WriteCompilerDetectionHeader module to generate a define
for that feature with portability fallbacks. For the avoidance of
making it easy to write code which looks correct but which has odd
runtime behavior, don't set the define symbol at all if no
equivalent keyword is known.
The SunPro Fortran compiler uses "-F" instead of "-E" to request
preprocessing. The output does not go to stdout so use "-o" to
specify the output file.
This fixes the guess originally made by commit b6b37e30 (Makefile: Add
assembly and preprocessed targets for Fortran, 2014-11-05).
bb83cdaa Help: Add notes for topic 'AppleClang-5.1-features'
bd6b42c1 Features: Record for AppleClang 5.1
b341799e Tests: Fix RunCMake.CompileFeatures test NonValidTarget2 case
Fix capitalization of Qt4_FOUND variable when setting it to false in
this case. This caused find_package(Qt4) to appear successful when it
was not. Note that the legacy QT4_FOUND variable is unconditionally
overwritten at the end of the file with the value of Qt4_FOUND.
Brad King
Stephen Kelly
Ben Boeckel
Sergey Nikulov
Frank Park
David Coppa
Christoph Grüninger
Aku Kotkavuo
Evangelos Foutras
Robert Maynard
Rolf Eike Beer
Mark Abraham
James Bigler
Daniele E. Domenichelli
Kelly Thompson
Ben Boeckel
Alin Marin Elena
Daniel Scharrer
Christoph Grüninger