This is a new FortranCInterface.cmake module to replace the previous
prototype. All module support files lie in a FortranCInterface
directory next to it.
This module uses a new approach to detect Fortran symbol mangling. We
build a single test project which defines symbols in a Fortran library
(one per object-file) and calls them from a Fortran executable. The
executable links to a C library which defines symbols encoding all known
manglings (one per object-file). The C library falls back to the
Fortran library for symbols it cannot provide. Therefore the executable
will always link, but prefers the C-implemented symbols when they match.
These symbols store string literals of the form INFO:symbol[<name>] so
we can parse them out of the executable.
This module also provides a simpler interface. It always detects the
mangling as soon as it is included. A single macro is provided to
generate mangling macros and optionally pre-mangled symbols.
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.
The commit "Consider link dependencies for link language" taught CMake
to propagate linker language preference from languages compiled into
libraries linked by a target. It turns out this should only be done for
some languages, such as C++, because normally the language of the
program entry point (main) should be used.
We introduce variable CMAKE_<LANG>_LINKER_PREFERENCE_PROPAGATES to tell
CMake whether a language should propagate its linker preference across
targets. Currently it is true only for C++.
We set the variables to contain "-v", the verbose front-end output
option for PGI compilers. This enables detection of implicit link
libraries and directories for these compilers.
We set the variables to contain "-v", the verbose front-end output
option for Intel compilers. This enables detection of implicit link
libraries and directories for these compilers.
This teaches the implicit link line parsing code to recognize link lines
that do not have a full path to the linker executable. At least one
version of the Intel compiler on Linux invokes the linker as just "ld"
instead of "/usr/bin/ld".
The Sun Fortran compiler passes -zallextract and -zdefaultextract to the
linker so that all objects from one of its archives are included in the
link. This teaches the implicit options parser to recognize the flags.
We need to pass them explicitly on C++ link lines when Fortran code is
linked.
This removes the file-wise installation rules for Modules and Templates
and instead installs the whole directories. This approach is much less
error-prone. The old approach was left from before CMake had the
install(DIRECTORY) command.
Xcode adds extra link directories that point at the build tree, so
detection of implicit link directories is not reliable. Since Fortran
is not supported in Xcode we will not need implicit link information yet
anyway.
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.
This teaches the language configuration modules to load per-compiler
information for each language using the compiler id but no system name.
They look for modules named "Compiler/<id>-<lang>.cmake". Such modules
may specify compiler flags that do not depend on the platform.
Some SGI compilers define _SGI_COMPILER_VERSION in addition to the old
_COMPILER_VERSION preprocessor symbol. It is more distinctive, so we
should check it in case the old one is ever removed.
The SGI preprocessor /usr/lib/cpp produces bad output on this code:
#if 1
A
#elif 1
B
#else
C
#endif
Both 'A' and 'C' appear in the output! We work around the problem by
using '#elif 1' instead of '#else'.
This fixes detection of the SGI Fortran compiler id in -o32 mode.
This teaches the ExternalProject module to check the download URL file
name. If it is not a tarball (.tar, .tgz, .tar.gz) it is an error
because UntarFile does not yet understand other archive formats.
When tarball extraction fails we should still cleanup the temporary
extraction directory. Otherwise the next attempt will create a new
directory and the first one will never be removed.
This teaches Modules/Platform/Linux-SunPro-CXX.cmake the -rpath-link flag. The
SunPro C++ compiler does not have a '-Wl,' option, so we just pass the flag
directly.
This problem was exposed by the ExportImport test now that it links an
executable through the C++ compiler with the -rpath-link flag.
cmCTestScriptHandler, but have it load the new script CTestScriptMode.cmake
-> that makes it more flexible, also add a simple test that the system name
has been determined correctly
Alex
This creates cmCTestHG to drive CTest Update handling on hg-based work
trees. Currently we always update to the head of the remote tracking
branch (hg pull), so the nightly start time is ignored for Nightly
builds. A later change will address this.
See issue #7879. Patch from Emmanuel Christophe. I modified the patch
slightly for code style, to finish up some parsing details, and to fix
the test.
This enhances the Fortran compiler id detection by using a source that
can compile either as free or fixed format. As long as the compiler
knows it should preprocess the source file (.F) the identification can
work. Even free-format compilers may try fixed-format parsing if the
user specifies certain flags, so we must support both.
This creates new module ExternalProject.cmake to replace the prototype
AddExternalProject.cmake module. The interface is more refined, more
flexible, and better documented than the prototype.
This also converts the ExternalProject test to use the new module. The
old module will be removed (it was never in a CMake release) after
projects using it have been converted to the new module.
On HP-UX machines some system libraries appear in architecture-specific
implicit linker search paths. We need to add these paths to our system
library search path. However, at the time we construct the search path
we do not know the target architecture.
A full solution requires re-organizing platform configuration files so
that the target architecture can be known when needed. Until that
happens we can avoid the problem by searching in both 32-bit and 64-bit
implicit link directories. By telling CMake that they are implicit
directories the generated link lines will never pass the paths, leaving
the linker free to find the library of the proper architecture even if
the find_library call finds the wrong one.
This adds the Modules/Platform/OpenVMS.cmake platform file for OpenVMS.
We just use Unix-like rules to work with the GNV compiler front-end.
A problem with process execution currently prevents CMake link scripts
from working, so we avoid using them.
HP-UX uses both .sl and .so as extensions for shared libraries. This
teaches CMake to recognize .so shared libraries so they are treated
properly during link dependency analysis.
This enables the --enable-auto-import linker flag on Cygwin when linking
executables. It works with the old gcc 3.x compiler and is necessary
for the new gcc 4.x compiler. See issue #9071.
Brad King
Ken Martin
Philip Lowman
Clinton Stimpson
David Cole
Bill Hoffman
Alexander Neundorf