summaryrefslogtreecommitdiff
path: root/Modules/CMakeFortranCompiler.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* Link step: use linker dependency linker fileMarc Chevrier2023-05-031-0/+1
| | | | | | Based on work done by @ben.boeckel (!8051) Fixes: #22217
* Fortran: Recognize f03, F03, f08 and F08 as extensionsTarun Prabhu2023-03-161-1/+1
|
* Apple: Handle generation and comsuption of text-based stubs (.tbd files)Marc Chevrier2023-03-011-0/+1
| | | | Fixes: #24123
* Fortran: Support cuf file extension when using nvfortranRobert Maynard2022-11-161-1/+1
|
* Merge topic 'IntelLLVM-Fortran-frontend-variant'Brad King2021-11-121-0/+1
|\ | | | | | | | | | | | | b1edd6e7c7 Fortran: Save frontend variant persistently for IntelLLVM Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6718
| * Fortran: Save frontend variant persistently for IntelLLVMWilliam R. Dieter2021-11-111-0/+1
| | | | | | | | | | | | | | | | | | Since commit a90d2a9eed (IntelLLVM: Add support for Intel LLVM-based compilers, 2020-11-02, v3.20.0-rc1~89^2~20), our IntelLLVM compiler support populates `CMAKE_Fortran_COMPILER_FRONTEND_VARIANT`. However, the frontend variant was not stored in `CMakeCompilerFortran.cmake`. Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
* | MINGW: Define variable only when targeting Windows platformsBrad King2021-09-171-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `MINGW` variable indicates that the compiler targets MinGW, a GNU ABI on Windows. Since commit aff3147917 (Modernize GNU compiler info on Windows, 2009-12-02, v2.8.2~636), we load the `Platform/Windows-GNU` module for compilers targetin MinGW, so set the variable there instead. This is equivalent to `Platform/Windows-MSVC` setting the `MSVC` variable. Also remove `if(MINGW)` checks from the module, which have not been necessary since the enclosed logic was moved to that module. The undocumented `CMAKE_COMPILER_IS_MINGW` internal variable is now unused, so remove it too. Fixes: #22647
* | Cygwin: Remove redundant definitions of CYGWIN and UNIX variablesBrad King2021-09-161-5/+0
|/ | | | | | | | These are set by modules loaded for `CMAKE_SYSTEM_NAME`. We do not need to set them again if the compiler defines `__CYGWIN__`. Also remove the now-unused undocumented `CMAKE_COMPILER_IS_CYGWIN` internal variable.
* Compilers: Add paths from -print-sysroot to system prefix pathRobert Maynard2020-04-141-0/+1
|
* XL: Add support for Ninja and XL FortranBrad King2019-11-211-0/+1
| | | | | | | | | | | | | | | The Ninja generator's support for Fortran requires that source files be preprocessed explicitly first. However, the `xlf` compiler does not have a simple `-E` option or equivalent to do preprocessing. The only documented way to get preprocessed output is to use `-d` to leave it behind, but only at an inflexible location. Instead, create our own `cpp` wrapper script and substitute it for the real preprocessor using `-tF -B ...`. Teach the wrapper to map the `cpp` output to the location we need and then invoke the real `cpp` underneath. Fixes: #19450
* ParseImplicitIncludeInfo: add Fortran implicit include handlingChuck Cranor2019-01-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Currently cmake is only setting CMAKE_Fortran_IMPLICIT_INCLUDE_DIRECTORIES the first time it runs (the implicit includes parser is only run when the cache variables are initially populated). It is left unset during additional runs. This behavior is both confusing and inconsistent. Modify CMakeFortranCompiler.cmake.in to preserve the value of CMAKE_Fortran_IMPLICIT_INCLUDE_DIRECTORIES so that cmake's Fortran behavior matches C and CXX (i.e. CMAKE_Fortran_IMPLICIT_INCLUDE_DIRECTORIES retains its value across runs). The implicit includes variable may not be as useful for Fortran as it is for C and CXX, but we do want cmake to be consistent in how it is handled. Adjust CMakeParseImplicitIncludeInfo to parse verbose Fortran output for Cray and XL compiler IDs (GNU and clang were already ok since they use the same verbose output format as they do with C/CXX). Allow Tests/RunCMake/ParseImplicitIncludeInfo/data/CMakeLists.txt to generate test inputs for Fortran too, and add some sample Fortran input files for the Tests/RunCMake/ParseImplicitIncludeInfo test.
* Fortran: Add support for .fpp extensionsBrad King2018-04-021-1/+1
| | | | | | | Compilers such as `gfortran` recognize `.fpp` extensions to mean a Fortran source on which the preprocessor should run. Fixes: #17869
* Add a CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID variableNorbert Lange2017-06-291-0/+1
| | | | | | | | | | Compilers such as MSVC and IAR may have variants that target different architectures. We have been using a `MSVC_<LANG>_ARCHITECTURE_ID` variable to hold this information for MSVC. Add an alternative with a more general name (later we can port MSVC to it too). This additional information may be needed to generate proper invocations of the compiler based on its architecture variant.
* Rename CMAKE_GCC_{AR,RANLIB} to CMAKE_LANG_COMPILER_{AR,RANLIB}Ruslan Baratov2017-04-031-2/+2
| | | | | | The variables recently added by commit b9d36826 (Add 'CMAKE_GCC_AR' and 'CMAKE_GCC_RANLIB' variables, 2017-03-08) are more appropriately managed with language-specific names rather than toolchain-specific names.
* Add 'CMAKE_GCC_AR' and 'CMAKE_GCC_RANLIB' variablesRuslan Baratov2017-03-091-0/+2
|
* Fortran: Use -isysroot and -mmacosx-version-min= on macOS if availableBrad King2016-08-301-0/+2
| | | | Closes: #16265
* CMakeDetermine*Compiler: Add hook to save custom compiler informationBrad King2016-08-121-0/+2
| | | | | | Provide a way for Platform/<os>-Determine-<lang>.cmake modules to save platform-specific information about the compiler in the configured CMake<lang>Compiler.cmake modules.
* Compiler: Add infrastructure for detecting compiler wrappersChuck Atkins2015-12-071-0/+1
|
* Revert "Disable shared library support when compiler links statically" (#15855)Brad King2015-11-231-1/+0
| | | | | | | | In commit v3.4.0-rc1~18^2 (Disable shared library support when compiler links statically, 2015-09-30) we tried to detect when the compiler is not capable of linking shared libraries (possibly due to flags in use). However, the approach is not robust against flags like `-nostdlib`. Revert it for now pending another solution to the original problem.
* Disable shared library support when compiler links staticallyBrad King2015-09-301-0/+1
| | | | | | | | | When a user or a compiler wrapper adds '-static' to the compiler flags then it will always link static binaries. Detect this from the compiler id binary and disable TARGET_SUPPORTS_SHARED_LIBS. This will prevent projects from accidentally adding shared libraries when the toolchain does not support them. It also helps CMake avoid linking with flags that require shared libraries to be supported.
* Fortran: Store detected compiler version persistently (#15684)Brad King2015-08-051-0/+1
| | | | | | | | The Fortran compiler version detection infrastructure added by commit v3.3.0-rc1~436^2~9 (Fortran: Add infrastructure to detect compiler version, 2015-02-17) forgot to update CMakeFortranCompiler.cmake.in to save the compiler version persistently as we do already in "CMake{C,CXX}Compiler.cmake.in". Add the missing line now.
* Intel: When simulating MSVC, re-use Windows-MSVC (#14476)Brad King2013-10-181-0/+2
| | | | | | | | | Teach CMake(C|CXX|Fortran)CompilerId* to report the MSVC version simulated by the Intel compiler, if any. Refactor the Windows-Intel platform information helper module to load Windows-MSVC instead of duplicating the information. Teach Windows-MSVC to understand when it is loaded as the simulated Fortran compiler (its preprocessor is simulated).
* OS X: Detect implicit linker framework search pathsBrad King2012-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we hard-coded a list of implicit framework directories but did not account for CMAKE_OSX_SYSROOT or for changes to the list across OS X versions. Instead we should automatically detect the framework directories for the active toolchain. The parent commit added the "-Wl,-v" option to ask "ld" to print its implicit directories. It displays a block such as: Framework search paths: /... Parse this block to extract the list of framework directories. Detection may fail on toolchains that do not list their framework directories, such as older OS X linkers. Always treat the paths <sdk>/Library/Frameworks <sdk>/System/Library/Frameworks <sdk>/Network/Library/Frameworks # Older OS X only /System/Library/Frameworks as implicit. Note that /System/Library/Frameworks should always be considered implicit so that frameworks CMake finds there will not override the SDK copies.
* Store ABI detection results in compiler information filesBrad King2012-08-241-0/+1
| | | | | | | | | | Drop use of cache entry CMAKE_DETERMINE_<LANG>_ABI_COMPILED and replace it with variable CMAKE_<LANG>_ABI_COMPILED. Since the grandparent commit this test result is specific to the version of CMake. Store it in the version-specific compiler information files instead of CMakeCache.txt so testing can be re-done to meet the requirements of the current version of CMake even if another version of CMake was already used to configure the build tree.
* Move CMAKE_<LANG>_COMPILER_WORKS to compiler information filesBrad King2012-08-241-0/+1
| | | | | | | | Since the parent commit this test result is specific to the version of CMake. Store it in the version-specific compiler information files instead of CMakeCache.txt so testing can be re-done to meet the requirements of the current version of CMake even if another version of CMake was already used to configure the build tree.
* Remove CMake-language block-end command argumentsKitware Robot2012-08-131-5/+5
| | | | | | | | | | | | | | | | | 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
* Convert CMake-language commands to lower caseKitware Robot2012-08-131-45/+45
| | | | | | | | | | | | | | | | | Ancient CMake versions required upper-case commands. Later command names became case-insensitive. Now the preferred style is lower-case. Run the following shell code: cmake --help-command-list | grep -v "cmake version" | while read c; do echo 's/\b'"$(echo $c | tr '[:lower:]' '[:upper:]')"'\(\s*\)(/'"$c"'\1(/g' done >convert.sed && git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' | egrep -z -v '^(Utilities/cm|Source/kwsys/)' | xargs -0 sed -i -f convert.sed && rm convert.sed
* Teach find_(library|package) about Linux multiarch (#12037)Brad King2011-06-081-0/+5
| | | | | | | | | | | | | Implement support for multiarch as specified here: http://wiki.debian.org/Multiarch https://wiki.ubuntu.com/MultiarchSpec Detect the <arch> part of <prefix>/lib/<arch> from the implicit library search path from each compiler to set CMAKE_<lang>_LIBRARY_ARCHITECTURE. Define CMAKE_LIBRARY_ARCHITECTURE using one of these values (they should all be the same). Teach the find_library and find_package commands to search <prefix>/lib/<arch> whenever they would search <prefix>/lib.
* Detect Fortran target architecture on WindowsBrad King2010-12-161-0/+1
| | | | | | | Commit 4430bccc (Change the way 32/64 bit compiles are detected with MSVC and intel, 2009-11-19) added detection of the target processor to C and CXX language builds with MS and Intel tools. Do the same for Intel Fortran for Windows (ifort). Use /machine:<arch> to link executables.
* Use Fortran ABI detection results conservativelyBrad King2010-05-051-2/+2
| | | | | | | | | | We set CMAKE_Fortran_SIZEOF_DATA_PTR in the Fortran compiler information file after detecting the compiler ABI. However, since Fortran does not really have pointers, the preprocessor-based detection is unreliable. The result is needed to set CMAKE_SIZEOF_VOID_P only for Fortran-only projects because the value can come from C or C++ compilers otherwise. Therefore when CMAKE_SIZEOF_VOID_P is available from another language we should defer to it.
* Detect Fortran ABI InformationBrad King2010-01-121-0/+12
| | | | | | | Implement Fortran 32/64-bit ABI detection on some platforms. We need to set CMAKE_SIZEOF_VOID_P correctly in Fortran-only projects so that the find_library() command knows whether to look for 64-bit binaries. We also detect ELF binaries to enable RPATH replacement. See issue #10119.
* Pass Fortran90 test result to try-compileBrad King2009-07-301-0/+2
| | | | | | | This stores CMAKE_Fortran_COMPILER_SUPPORTS_F90 in the Fortran compiler information file CMakeFiles/CMakeFortranCompiler.cmake instead of in CMakeCache.txt. This file makes the result available to try-compile projects.
* ENH: Implicit link info for C, CXX, and FortranBrad King2009-07-231-0/+3
| | | | | | | | | | | | | This teaches CMake to detect implicit link information for C, C++, and Fortran compilers. We detect the implicit linker search directories and implicit linker options for UNIX-like environments using verbose output from compiler front-ends. We store results in new variables called CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES The implicit libraries can contain linker flags as well as library names.
* ENH: Patch from Maik to add more fortran extensions.Brad King2008-03-051-1/+1
|
* ENH: second try for handling the linker language with integer priority ↵Alexander Neundorf2007-07-121-1/+1
| | | | | | values (returning a pointer to a string on the stack is no good idea) Alex
* COMP: revert last commit for now, broke Visual StudioAlexander Neundorf2007-07-111-1/+1
| | | | Alex
* ENH: CMAKE_<LANG>_LINKER_PREFERENCE is now an integer priority, not aAlexander Neundorf2007-07-111-1/+1
| | | | | | | | | | | | | | | | | | | two-step priority (None or Prefered) Current order: ASM 0, C 10, Fortran 20, CXX 30, Java 40 This is the same order as automake choses: http://www.gnu.org/software/automake/manual/html_node/How-the-Linker-is-Chosen.html This change should be backward compatible: if there is a project using fortran and CXX, they had to set the LINKER_LANGUAGE explicitely, otherwise cmake complained (but still generated the project files). Explicitely setting the linker language still overrides automatic detection. If somebody has a custom language for cmake and the PREFERENCE starts with "P", its changed to 100, which gives it preference over all other languages (except the other custom languages which have also "Prefered"). "None" is converted to 0. Alex
* ENH: Merging CompilerId updates from branch CMake-Modules-CompilerId to the ↵Brad King2007-05-031-2/+5
| | | | main tree. Changes between CMake-Modules-CompilerId-mp1 and CMake-Modules-CompilerId-mp2 are included.
* ENH: Merge debian changes. Support more fortran extensionsAndy Cedilnik2006-07-041-1/+1
|
* ENH: make sure flags set in CC or CXX environment variables stay with the ↵Bill Hoffman2005-07-201-0/+1
| | | | compiler
* ENH: stuff to keep compiler tests from re-running all the timeBill Hoffman2005-01-201-0/+1
|
* BUG: fix GNU check variable and add new variables used by enable languageBill Hoffman2004-09-221-1/+8
|
* ENH: define language extensions in cmake files and not hard coded, also fix ↵Bill Hoffman2004-09-031-0/+1
| | | | trycompile problem
* ENH: more uniform approach to enable language, one step closer to being able ↵Bill Hoffman2004-08-261-2/+2
| | | | to enable a language without modifing cmake source code
* ENH: initial fortran supportBill Hoffman2004-08-061-0/+16
View Lorry Controller Status