| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
PathScale Fortran mangles module symbols as "MY_SUB.in.MY_MODULE" and
also requires "my_module_" when the module is imported. We cannot
provide the symbol with ".in." mangling so we should not provide
"my_module_" because it would duplicate the one in the Fortran-provided
object file.
Commit "FortranCInterface: Fix PathScale detection" (2010-01-22) already
made the same fix for the non-underscore module case.
|
| |
|
|
|
|
|
| |
PathScale Fortran mangles module symbols as "MYSUB.in.MYMODULE" and also
requires "mymodule_" when the module is imported. We cannot provide the
symbol with ".in." mangling so we should not provide "mymodule_" because
it would duplicate the one in the Fortran-provided object file.
|
| |
|
|
|
|
|
|
| |
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 Intel Fortran compiler for Windows uses upper-case symbol names with
no trailing underscore.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
The verification program entry point (main) is defined in a C source
file, so the C compiler should be used to link when only Fortran and C
are involved. The C++ compiler should still be used when the CXX option
is enabled.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
The old GNU g77 Fortran compiler uses the suffix '__' for symbols
containing an underscore in their name.
|
| |
|
|
|
| |
This just cleans up the list ordering so more entries can be added while
keeping everything organized.
|
| |
|
|
|
| |
This documents the purpose of the extra my_module_.c and mymodule.c
source files, and sorts the symbols.
|
| | |
|
|
|
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.
|
