summaryrefslogtreecommitdiffstats
path: root/Modules/FortranCInterface
Commit message (Collapse)AuthorAgeFilesLines
* FortranCInterface: Fix cross-compiling Linux to MinGW (#14358)Michel Zou2013-08-141-1/+1
| | | | | | | | | After building the test binary tell find_program to search for it with the ${CMAKE_EXECUTABLE_SUFFIX} so that the .exe can be found. Since find_program is normally used to locate host tools while cross-compiling it needs this hint to find the target binary. Suggested-by: Denis Barbier <bouzim@gmail.com>
* Remove CMake-language block-end command argumentsKitware Robot2012-08-131-1/+1
| | | | | | | | | | | | | | | | | 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
* Move IntelVSImplicitPath project to better locationBrad King2011-09-143-23/+0
| | | | | This project is not part of the FortranCInterface module. Make it a sibling instead of a child directory.
* For VS Intel Fortran IDE builds, add a check to find the Fortran library PATH.Bill Hoffman2011-09-083-0/+23
| | | | | | | | To use VS C and Fotran in the same solution, it is required that VS be able to find the Fortran run time libraries as they will be implicitly linked by any Fortran library used by VS C programs. This adds a check into CMakeDetermineCompilerABI using a try-compile to find the correct PATH.
* FortranCInterface: Compile separate Fortran lib in VerifyC[XX]Brad King2011-09-081-1/+3
| | | | | | | The Intel Fortran plugin for Visual Studio requires Fortran source files to be compiled in a separate target from C and C++ code. Compile the VerifyFortran.f source file in a separate library and link the main VerifyFortanC executable to it.
* 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 18:13:10 (GMT)