Provide a way for Platform/<os>-Determine-<lang>.cmake modules to save
platform-specific information about the compiler in the configured
CMake<lang>Compiler.cmake modules.
In commit v3.4.0-rc1~18^2 (Disable shared library support when compiler
links statically, 2015-09-30) we tried to detect when the compiler is
not capable of linking shared libraries (possibly due to flags in use).
However, the approach is not robust against flags like `-nostdlib`.
Revert it for now pending another solution to the original problem.
When a user or a compiler wrapper adds '-static' to the compiler flags
then it will always link static binaries. Detect this from the compiler
id binary and disable TARGET_SUPPORTS_SHARED_LIBS. This will prevent
projects from accidentally adding shared libraries when the toolchain
does not support them. It also helps CMake avoid linking with flags
that require shared libraries to be supported.
The Fortran compiler version detection infrastructure added by commit
v3.3.0-rc1~436^2~9 (Fortran: Add infrastructure to detect compiler
version, 2015-02-17) forgot to update CMakeFortranCompiler.cmake.in to
save the compiler version persistently as we do already in
"CMake{C,CXX}Compiler.cmake.in". Add the missing line now.
Teach CMake(C|CXX|Fortran)CompilerId* to report the MSVC version
simulated by the Intel compiler, if any. Refactor the Windows-Intel
platform information helper module to load Windows-MSVC instead of
duplicating the information. Teach Windows-MSVC to understand when
it is loaded as the simulated Fortran compiler (its preprocessor is
simulated).
Previously we hard-coded a list of implicit framework directories but
did not account for CMAKE_OSX_SYSROOT or for changes to the list across
OS X versions. Instead we should automatically detect the framework
directories for the active toolchain.
The parent commit added the "-Wl,-v" option to ask "ld" to print its
implicit directories. It displays a block such as:
Framework search paths:
/...
Parse this block to extract the list of framework directories.
Detection may fail on toolchains that do not list their framework
directories, such as older OS X linkers. Always treat the paths
<sdk>/Library/Frameworks
<sdk>/System/Library/Frameworks
<sdk>/Network/Library/Frameworks # Older OS X only
/System/Library/Frameworks
as implicit. Note that /System/Library/Frameworks should always be
considered implicit so that frameworks CMake finds there will not
override the SDK copies.
Drop use of cache entry CMAKE_DETERMINE_<LANG>_ABI_COMPILED and replace
it with variable CMAKE_<LANG>_ABI_COMPILED. Since the grandparent
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.
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
Implement support for multiarch as specified here:
http://wiki.debian.org/Multiarchhttps://wiki.ubuntu.com/MultiarchSpec
Detect the <arch> part of <prefix>/lib/<arch> from the implicit library
search path from each compiler to set CMAKE_<lang>_LIBRARY_ARCHITECTURE.
Define CMAKE_LIBRARY_ARCHITECTURE using one of these values (they should
all be the same). Teach the find_library and find_package commands to
search <prefix>/lib/<arch> whenever they would search <prefix>/lib.
Commit 4430bccc (Change the way 32/64 bit compiles are detected with
MSVC and intel, 2009-11-19) added detection of the target processor to C
and CXX language builds with MS and Intel tools. Do the same for Intel
Fortran for Windows (ifort). Use /machine:<arch> to link executables.
We set CMAKE_Fortran_SIZEOF_DATA_PTR in the Fortran compiler information
file after detecting the compiler ABI. However, since Fortran does not
really have pointers, the preprocessor-based detection is unreliable.
The result is needed to set CMAKE_SIZEOF_VOID_P only for Fortran-only
projects because the value can come from C or C++ compilers otherwise.
Therefore when CMAKE_SIZEOF_VOID_P is available from another language we
should defer to it.
Implement Fortran 32/64-bit ABI detection on some platforms. We need to
set CMAKE_SIZEOF_VOID_P correctly in Fortran-only projects so that the
find_library() command knows whether to look for 64-bit binaries. We
also detect ELF binaries to enable RPATH replacement. See issue #10119.
This stores CMAKE_Fortran_COMPILER_SUPPORTS_F90 in the Fortran compiler
information file CMakeFiles/CMakeFortranCompiler.cmake instead of in
CMakeCache.txt. This file makes the result available to try-compile
projects.
This teaches CMake to detect implicit link information for C, C++, and
Fortran compilers. We detect the implicit linker search directories and
implicit linker options for UNIX-like environments using verbose output
from compiler front-ends. We store results in new variables called
CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES
CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES
The implicit libraries can contain linker flags as well as library
names.
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