When using a Visual Studio generator with an Intel toolset, such as
-T "Intel C++ Compiler XE 14.0"
the generated FortranCInterface mangling detection project may fail to
build due to `devenv` not working with the `/project ALL_BUILD` option.
This seems to be a bug in `devenv` or the Intel VS integration. Work
around the problem by building with `/project FortranCInterface`
instead. We only need to build this executable and its dependencies
within the detection test project anyway.
Fixes: #16519
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
Some projects may want to use the detailed mangling information
directly instead of using the FortranCInterface_HEADER function.
We already provide variables encoding the mangling information,
so just document them as available.
Do not force a specific policy version in the module because it prevents
projects from setting newer policies to NEW. In particular, projects
may want to set CMP0056 to NEW to affect any try_compile calls in this
module.
Use of this was added in commit v2.8.2~714 (FortranCInterface: Use CMake
2.8.0 behavior, 2009-11-17) in order to set CMP0007 to NEW. Simply set
this policy explicitly instead.
Teach FortranCInterface_VERIFY to build the test project in a specific
configuration and pass all flags for that configuration. This ensures
that any modifications made by the user or project to the flag are used in
the test project consistently.
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
The mingw32-make tool does not handle parenthesis in the path to a
source file consistently. When CMake is installed in a typical location
like "c:\Program Files (x86)\CMake 2.8\" the mingw32-make tool fails on
the FortranCInterface detection project sometimes with errors like
>mingw32-make -f CMakeFiles\myfort.dir\build.make CMakeFiles/myfort.dir/my_module.f90.obj
mingw32-make: *** No rule to make target `x86)/CMake 2.8/share/cmake-2.8/Modules/FortranCInterface/my_module.f90)',
needed by `CMakeFiles/myfort.dir/my_module.f90.obj'. Stop.
due to parens in the path to the FortranCInterface source directory.
However, the behavior varies with the file name of build.make:
>copy CMakeFiles\myfort.dir\build.make CMakeFiles\myfort.dir\build2.make
>mingw32-make -f CMakeFiles\myfort.dir\build2.make CMakeFiles/myfort.dir/my_module.f90.obj
[ 3%] Building Fortran object CMakeFiles/myfort.dir/my_module.f90.obj
Tested with
>mingw32-make -v
GNU Make 3.82
Built for i386-pc-mingw32
Work around the problem by copying the whole FortranCInterface source
directory in to the project build tree.
The commit "FortranCInterface: Honor language flags in checks" taught
the FortranCInterface module to pass C and Fortran flags into its
detection and verification checks. We improve on the change to allow
the '=' character in the language flags. This requires passing the
cache entry type with the -D options.
We pass CMAKE_C_FLAGS, CMAKE_CXX_FLAGS, and CMAKE_Fortran_FLAGS through
try_compile() for the FortranCInterface Detect and Verify projects.
This honors user-specified compiler flags for each language, thus
supporting flags that affect the Fortran mangling.
The FortranCInterface module should execute with CMake 2.8.0 behavior
even if policies are set differently by the including project. In
particular, it makes use of empty list elements and therefore expects
NEW behavior of CMP0007.
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.
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.
We split the main detection logic into a Detect.cmake support module and
load it only when detection results are not already available. This
allows results computed by the main project to be used in try-compile
projects without recomputing them. The call to try_compile() need only
to pass FortranCInterface_BINARY_DIR through the CMAKE_FLAGS option.
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.
