summaryrefslogtreecommitdiffstats
path: root/Modules/FortranCInterface
Commit message (Collapse)AuthorAgeFilesLines
* FortranCInterface: Fix mangling detection with Cray Fortran >= 7.3.2Brad King2011-03-243-15/+12
| | | | | | | | | | | | | | | The Cray Fortran compiler started using module init symbols in version 7.3.2. Starting in commit 71287734 (Teach FortranC interface for Intel, PGI, and gcc 4.2, 2009-08-05) we provide C versions of the module init symbols so that the detection executable can link when the C versions of the module-mangled symbols are picked up. If no C module-mangled symbol matches then we cannot let the C module init symbol appear because it will be duplicated by the Fortran copy that provides the module-mangled symbol. This was first handled for the PathScale compiler in commit 21faaa5d (FortranCInterface: Fix PathScale detection, 2010-01-22) and commit 46858720 (FortranCInterface: Fix PathScale detection again, 2010-02-16). Handle it now for the Cray compiler too.
* FortranCInterface: Recognize NAG Fortran module symbolsBrad King2010-12-091-0/+2
|
* FortranCInterface: Fix PathScale detection againBrad King2010-02-161-0/+6
| | | | | | | | | | | 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.
* FortranCInterface: Fix PathScale detectionBrad King2010-01-222-0/+7
| | | | | | | 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.
* FortranCInterface: Support '=' in language flagsBrad King2009-12-151-2/+2
| | | | | | | | 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.
* FortranCInterface: Honor language flags in checksBrad King2009-11-191-0/+3
| | | | | | | 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.
* FortranCInterface: Mangling for Intel on WindowsBrad King2009-10-051-0/+4
| | | | | The Intel Fortran compiler for Windows uses upper-case symbol names with no trailing underscore.
* Convert CMake non-find modules to BSD LicenseBrad King2009-09-283-0/+33
| | | | | | | 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.
* Fix FortranCInterface_VERIFY for non-C++ caseBrad King2009-09-011-0/+5
| | | | | | | 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.
* Create FortranCInterface_VERIFY functionBrad King2009-08-246-0/+48
| | | | | | | 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.
* Teach FortranCInterface to load outside resultsBrad King2009-08-241-0/+165
| | | | | | | | 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.
* Teach FortranCInterface about g77 manglingBrad King2009-08-061-0/+1
| | | | | The old GNU g77 Fortran compiler uses the suffix '__' for symbols containing an underscore in their name.
* Sort FortranCInterface global mangling symbolsBrad King2009-08-061-2/+2
| | | | | This just cleans up the list ordering so more entries can be added while keeping everything organized.
* Cleanup FortranCInterface for PGI and GCC 4.2Brad King2009-08-053-8/+10
| | | | | This documents the purpose of the extra my_module_.c and mymodule.c source files, and sorts the symbols.
* Teach FortranC interface for Intel, PGI, and gcc 4.2Bill Hoffman2009-08-053-2/+8
|
* Rewrite FortranCInterface moduleBrad King2009-08-0512-0/+154
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.
generated by cgit v0.12 at 2024-11-11 11:13:12 (GMT)