| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This teaches the Fortran test to try all basic target types (archive,
shared lib, exe) with Fortran-only sources.
|
|
|
|
|
|
|
| |
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 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
|
|
|