The languages used in compiling STATIC libraries need to be propagated
to dependents regardless of the settings of INTERFACE_LINK_LIBRARIES or
CMP0022. They are independent of the libraries in the link interface.
Prior to commit v2.8.12~192^2~2 (Introduce the INTERFACE_LINK_LIBRARIES
property, 2013-06-04) the cmTarget::ComputeLinkInterface code path for
"explicitLibraries" could never be taken for STATIC libraries, so the
logic to propagate languages existed only in the non-explicitLibraries
code path. After that commit, INTERFACE_LINK_LIBRARIES could be set for
STATIC libraries to cause the "explicitLibraries" code path to be taken.
The commit also left the old non-explicitLibraries code path conditional
on CMP0022 not being set to NEW. Thus link language propagation was
left missing from two cases by that commit.
The explicitLibraries code path was fixed to propagate languages by
commit v2.8.12~149^2~1 (cmTarget: Fix iface libraries and languages for
static libraries, 2013-07-26). However, the non-explicitLibraries case
was never taught to propagate languages when CMP0022 is set to NEW. Fix
that now. Factor the logic to propagate link languages out of the link
interface libraries conditions so that it always occurs. Update
Tests/Fortran to set CMP0022 to NEW to test this case (because the test
passes only if link language propagation works).
Since commit fd6076d0 (Tests: Pass CMAKE_MAKE_PROGRAM instead of
--build-makeprogram, 2013-11-15) the ExportImport, Fortran, and
MacRuntimePath tests use the value of CMAKE_TEST_MAKEPROGRAM as the
CMAKE_MAKE_PROGRAM for their nested projects configurations.
Teach these tests to initialize CMAKE_TEST_MAKEPROGRAM when it is
not provided, such as when building the tests manually.
Pass the CMAKE_TEST_MAKEPROGRAM, if any, to each test at CMake time in
the CMAKE_MAKE_PROGRAM cache entry. Pass the CMAKE_TEST_MAKEPROGRAM
into the ExportImport, Fortran, and MacRuntimePath tests so that they
may do the same for the nested project configurations.
Now "ctest --build-and-test" can get the make program from the test
build tree cache, so drop the explicit --build-makeprogram.
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
Since commit 38aab379 (Set CMAKE_<lang>_COMPILER_ID for VS generators,
2011-09-02) the VS IDE generators set the C and C++ compiler id to MSVC
and the Fortran compiler id to Intel. This caused the Fortran test to
fail compatible compiler detection because the if() test
"${CMAKE_C_COMPILER_ID}" MATCHES "MSVC"
is evaluated as the "var MATCHES regex" signature which evaluates the
compiler id "MSVC" as a variable which is defined to 1 which does not
match "MSVC".
Combine tests for non-identical but compatible compiler vendors into a
single regex match whose left hand side will not be defined as a
variable.
Define a "Fortran_FORMAT" target and source file property. Initialize
the target property from a "CMAKE_Fortran_FORMAT" variable. Interpret
values "FIXED" and "FREE" to indicate the source file format. Append
corresponding flags to the compiler command line.
8bd3e51 Absoft: Enable FortranCInterface check in Fortran test
d7b376b Absoft: Detect implicit link libraries on Linux and Mac
ac5b999 Add Absoft Fortran compiler id and basic flags
Commit 6a61a8a5 (Honor module .def files with MinGW tools, 2011-02-21)
enabled use of .def files with GNU tools on Windows. Previously the
Fortran tests's world.def file was used only for the Intel Fortran
Compiler on Windows and contained the symbol name mangled for that
compiler. Instead choose a .def file that names the symbol with proper
mangling for the compiler in use.
We disable this test because PathScale Fortran mangles module symbols as
"MYSUB.in.MYMODULE" so we cannot interface with it from C. We already
did this for SunPro and MIPSpro.
Makefile dependencies must be escaped using cmLocalGenerator::Convert
with the cmLocalGenerator::MAKEFILE option. This fixes Fortran module
dependencies with spaces in the path. We test the fix by adding a space
to one of the module paths in the Fortran test.
The commit "Test all target types in Fortran" enabled a SHARED library
in the Fortran test. However, we do not yet implement support for
shared libraries with XL Fortran (it seems this requires using the C
compiler to link). Furthermore, the old g77 2.97 from Red Hat does not
support shared libs on Itanium because the g2c lib is not -fPIC.
For now we just disable SHARED libs in the test for these tools.
We add Intel and MinGW Fortran linker options to create the import
library portion of a DLL. This allows other binaries to link to a
Fortran DLL.
We also update the Fortran test to use a .def file to specify exports
since there is no __declspec(dllexport) markup syntax in Fortran.
In the Fortran test we use a custom command to build another Fortran
project internally. The project provides a Fortran module and library
to which to link. This commit teaches the test to build the extra
project using the same build configuration as the main project.
CMake now looks for a Fortran compiler matching any C or C++ compiler
already enabled. We test this by enabling C and C++ first in the
Fortran test, which is what user projects will likely do.
This function builds a simple test project using a combination of
Fortran and C (and optionally C++) to verify that the compilers are
compatible. The idea is to help projects report very early to users
that the compilers specified cannot mix languages.
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.
Previously the Fortran test created a single executable containing C,
C++, and Fortran sources. This commit divides the executable into three
libraries corresponding to each language, and two executables testing
Fortran/C only and Fortran/C/C++ together. The result tests more
combinations of using the languages together, and that language
requirements propagate through linking.
This extends the Fortran-to-C interface test to add a C++ source file.
The executable can only link with the C++ linker and with the proper
Fortran runtime libraries. These libraries should be detected by CMake
automatically, so this tests verifies the detection functionality.
This hack was created to help the Fortran test executables link to the
implicit C libraries added by BullsEye. Now that implicit libraries
from all languages are detected and included automatically the hack is
no longer needed.
Brad King
Kitware Robot
Bill Hoffman
Ken Martin