We deprecated this module in commit v3.5.0-rc1~295^2
(CMakeForceCompiler: Deprecate this module and its macros, 2015-10-19)
in order to determine whether anyone still has use cases that require
it. Indeed we still need to provide a way to work with toolchains that
cannot link binaries without special flags. Remove the deprecation
warnings until we can provide an alternative to the module for this use
case.
This module was added by commit v2.6.0~1489 (...supporting embedded
compilers..., 2007-07-02) to avoid needing to build the compiler id
detection source on toolchains that need special flags or linker files
to produce executables. Since then CMake has learned other ways to
identify such compilers (e.g. passing vendor-specific version flags and
checking for vendor-specific banners in the output). Furthermore, CMake
now detects a lot more than just the compiler id during language
initialization in order to support things like <LANG>_STANDARD and
COMPILE_FEATURES. Therefore CMakeForceCompiler is no longer a viable
approach because it skips such detection.
One remaining challenge to support toolchains that require special
linker files is to build the test for a working compiler, compiler ABI
detection binary, and other try_compile cases. This will have to be
worked out as such cases are encountered.
When testing CMAKE_<LANG>_COMPILER_ID values, do not explicitly
dereference or quote the variable. We want if() to auto-dereference the
variable and not its value. Also replace MATCHES with STREQUAL where
equivalent.
Since the parent commit this test result is specific to the version of
CMake. Store it in the version-specific compiler information files
instead of CMakeCache.txt so testing can be re-done to meet the
requirements of the current version of CMake even if another version of
CMake was already used to configure the build tree.
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
We add the macro CMAKE_FORCE_Fortran_COMPILER to the cross-compiling
helper module CMakeForceCompiler.cmake so that toolchain files can force
a Fortran compiler as well as C and C++ compilers. See issue #10032.
This adds copyright/license notification blocks CMake's non-find
modules. Most of the modules had no notices at all. Some had notices
referring to the BSD license already. This commit normalizes existing
notices and adds missing notices.
two-step priority (None or Prefered)
Current order: ASM 0, C 10, Fortran 20, CXX 30, Java 40
This is the same order as automake choses:
http://www.gnu.org/software/automake/manual/html_node/How-the-Linker-is-Chosen.html
This change should be backward compatible:
if there is a project using fortran and CXX, they had to set the
LINKER_LANGUAGE explicitely, otherwise cmake complained (but still generated
the project files). Explicitely setting the linker language still overrides
automatic detection.
If somebody has a custom language for cmake and the PREFERENCE starts with
"P", its changed to 100, which gives it preference over all other languages
(except the other custom languages which have also "Prefered"). "None" is
converted to 0.
Alex
compiling an executable (amd thus cannot build the compiler-id program)
easier by providing CMAKE_FORCE_XXX() macros which force cmake to use the
given compilers anyway
Alex
Brad King
Ben Boeckel
Kitware Robot
Todd Gamblin
Alexander Neundorf