| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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 removes the QUIET option from FortranCInterface_VERIFY in the
Fortran test to really test the detected interface everywhere.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
This extends the Fortran/C interface test to require that the executable
link to the fortran language runtime libraries. We must verify that the
proper linker is chosen.
|
|
|
|
|
| |
This extends the Fortran preprocessing test to include a header file
through a preprocessor directive.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
source.
|
| |
|
|
|
|
| |
dependency scanning. Also added -fpp flag to Intel Fortran compiler on Windows by default.
|
| |
|
|
|
|
| |
module path feature is needed for Sun support because it uses -M instead of -I for the module search path.
|
|
|
|
| |
external modules. Tests based on cases provided by Maik in issue #5809.
|
| |
|
|
|
|
| |
See bug#5809.
|
|
|
|
| |
never used.
|
| |
|
| |
|
|
|
|
| |
directory.
|
|
|
|
| |
other fortran compilers
|
|
|
|
| |
to enable a language without modifing cmake source code
|
|
|