summaryrefslogtreecommitdiff
path: root/Modules/CMakeDetermineFortranCompiler.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Modules: Record system inspection steps in the configure logBrad King2023-01-181-2/+2
| | | | | | | | Replace old-style `file(APPEND .../CMake{Output,Error}.log)` logging with calls to `message(CONFIGURE_LOG)` to record the steps in the `CMakeConfigureLog.yaml` configure log instead. Issue: #23200
* Fortran: Support cuf file extension when using nvfortranRobert Maynard2022-11-161-0/+3
|
* Fortran: cleanup compiler default search listMichael Hirsch2022-08-161-25/+11
| | | | | | Made GNU gfortran be last in the list as per the docstring immmediately preceding. One high-level version-free name per vendor.
* LLVMFlang: Add support for LLVM FlangTin Huynh2022-05-241-0/+1
| | | | | | | | | LLVM Flang (https://github.com/llvm/llvm-project/tree/main/flang) is an LLVM Fortran compiler that shares the same name as Flang (also known as Classic Flang). Classic Flang is in active development and is already identified by CMake as Flang. As such, LLVM Flang will be identified as `LLVMFlang`. Fixes: #22387
* Fortran: Support searching for the `nvfortran` executableRobert Maynard2022-01-101-2/+4
| | | | Instead of relying on the PGI symlinks (pgf95/pgf90/...) to always exist.
* LCC: Add dedicated support for MCST LCC compilermakise-homura2021-10-151-1/+2
| | | | | | | | | | | | | | | | | | | | | Divert LCC compiler as a new one, instead of treating it as GNU. Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been passing checks for GNU compilers, so it has been identified as GNU. Now, with intent of seriously upstreaming its support, it has been added as a separate LCC compiler, and its version displays not a supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead of GNU 7.3.0). This commit adds its support for detection, and also converts basically every check like 'is this compiler GNU?' to 'is this compiler GNU or LCC?'. The only places where this check is untouched, is where it regards other platforms where LCC is unavailable (primarily non-Linux), and where it REALLY differs from GNU compiler. Note: this transition may break software that are already ported to Elbrus, but hardly relies that LCC will be detected as GNU; still such software is not known.
* MINGW: Define variable only when targeting Windows platformsBrad King2021-09-171-3/+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-2/+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.
* IntelLLVM: Add support for Intel LLVM-based compilersWilliam R. Dieter2021-01-281-3/+5
| | | | | | | | | | | | | | | | | | Using a single ID 'IntelLLVM' for the suite of Intel compilers based on the LLVM backend. The 'IntelLLVM' ID are used for C, C++, and Fortran. Data Parallel C++ will be handled in a separate commit. The C and C++ definitions are based on the Clang definitions. The Intel LLVM-based C and C++ compilers are based on the Clang front end, so existing Clang options are more likely to be a good match than options for the older Intel compilers. Fortran is based on the older Fortran front end with the LLVM backend. It has a similar interface to the older versions, though many options are shared with the C and C++ compilers. Fixes: #21561 Signed-off-by: William R. Dieter <william.r.dieter@intel.com>
* Toolchain: Capture all arguments from CMAKE_<LANG>_COMPILERFred Baksik2020-07-231-1/+1
| | | | | | | | | | | Capture CMAKE_<LANG>_COMPILER_ARG1 from CMAKE_<LANG>_COMPILER in the same fashion that it is from $ENV{<LANG>}. Since get_filename_component() returns a single string of all the arguments from $ENV{<LANG>}, a single string of arguments will be constructed from the items contained in CMAKE_<LANG>_COMPILER. Fixes #20089
* Compilers: Add paths from -print-sysroot to system prefix pathRobert Maynard2020-04-141-0/+10
|
* DetermineCompiler: Relax _CMAKE_TOOLCHAIN_PREFIX detectionRobert Maynard2020-03-301-1/+1
| | | | | | Now detect _CMAKE_TOOLCHAIN_PREFIX whenever a compilers name matches the heuristics, instead of only doing it when cross compiling
* XL: Add support for Ninja and XL FortranBrad King2019-11-211-0/+5
| | | | | | | | | | | | | | | 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
* Fortran: Adjust compiler candidates based on host platformxoviat2018-02-211-6/+14
| | | | | | | | | Typical Fortran compiler command-line tool names differ on Windows and non-Windows platforms. Also, the name `ifc` should not be used on Windows because there is an `ifc.exe` tool in Visual Studio that is unrelated. Fixes: #17752
* CMakeFindBinUtils: Improve switch between MSVC- and GNU-like toolsBrad King2017-11-281-1/+1
| | | | | | | | The switch was not considering some languages, such as `ASM`. Instead of memorizing the list of languages in the condition, use a language specified by the includer. Fixes: #17510
* Flang: Add support for flang Fortran compilerTin Huynh2017-08-311-2/+4
| | | | | | | | | | | | | | flang is a Fortran compiler built on top of clang [1]. Because flang shares a lot of commonalities with clang, the flang module piggybacks off the clang module and overrides certain options. Add flang to Fortran compiler auto find list. Update flang preprocessor macros to differentiate from PGI. Add Flang-FindBinUtils. [1] https://github.com/flang-compiler/flang
* Add a CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID variableNorbert Lange2017-06-291-0/+7
| | | | | | | | | | 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.
* NAG: Extend compiler tool selection with NAG FortranTom Clune2017-05-051-1/+3
| | | | Add `nag` and `nagfor`.
* Add 'CMAKE_GCC_AR' and 'CMAKE_GCC_RANLIB' variablesRuslan Baratov2017-03-091-0/+3
|
* Simplify CMake per-source license noticesBrad King2016-09-271-12/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Per-source copyright/license notice headers that spell out copyright holder names and years are hard to maintain and often out-of-date or plain wrong. Precise contributor information is already maintained automatically by the version control tool. Ultimately it is the receiver of a file who is responsible for determining its licensing status, and per-source notices are merely a convenience. Therefore it is simpler and more accurate for each source to have a generic notice of the license name and references to more detailed information on copyright holders and full license terms. Our `Copyright.txt` file now contains a list of Contributors whose names appeared source-level copyright notices. It also references version control history for more precise information. Therefore we no longer need to spell out the list of Contributors in each source file notice. Replace CMake per-source copyright/license notice headers with a short description of the license and links to `Copyright.txt` and online information available from "https://cmake.org/licensing". The online URL also handles cases of modules being copied out of our source into other projects, so we can drop our notices about replacing links with full license text. Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority of the replacements mechanically. Manually fix up shebang lines and trailing newlines in a few files. Manually update the notices in a few files that the script does not handle.
* Use string(APPEND) in ModulesDaniel Pfeifer2016-07-281-3/+3
| | | | | | | Automate with: find Modules -type f -print0 | xargs -0 perl -i -0pe \ 's/set\(([a-zA-Z0-9_]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g'
* Modules: Rename internal platform-specific compiler determination modulesBrad King2016-06-021-0/+1
| | | | | | | Rename Modules/Platform/<os>-<lang>.cmake files to Modules/Platform/<os>-Determine-<lang>.cmake to clarify their role. For compatibility with user-provided modules, load the old names if they exist.
* Fortran: Fix platform id detection on mingw-w64Melven Roehrig-Zoellner2016-04-051-0/+15
| | | | | | | On mingw-w64 the GNU Fortran compiler does not define `__MINGW32__` or any similar indicator. Fix `CMAKE_Fortran_PLATFORM_ID` detection in this case by falling back to preprocessing a `.c` source file even when the compiler id is already detected.
* CMakeDetermineFortranCompiler: Modernize conventionsMelven Roehrig-Zoellner2016-04-051-6/+5
| | | | Suggested-by: Ben Boeckel <ben.boeckel@kitware.com>
* Fortran: Add ftn, the Cray compiler wrapper, to the default search.Chuck Atkins2015-12-041-0/+2
|
* CMakeDetermineCompilerId: Use per-language regex to match Xcode compiler toolBrad King2015-06-301-0/+8
| | | | | | Move the Ld invocation match expression from CMakeDetermineCompilerId into CMakeDetermine{C,CXX,Fortran}Compiler so that it can be specified on a per-language basis.
* Add support for Concurrent Fortran 77 CompilerBrad King2015-06-181-1/+8
| | | | | | | | | The Concurrent Fortran compiler (ccur.com) is available on Linux and can be used much like the GNU Fortran compiler. Currently it has no preprocessor symbols to identify it so we need to detect it by matching compiler output. Suggested-by: Anthony Ette <Anthony.R.Ette@controlsdata.com>
* CMakeDetermineCompilerId: Optionally try some flags before no flagsBrad King2015-06-181-0/+1
| | | | | | | | Teach CMAKE_DETERMINE_COMPILER_ID to optionally try detecting the compiler id using some given flags before trying to detect it with no special flags. This will be useful for Fortran detection to distinguish some compilers that use the preprocessors of others but have no macro of their own by getting verbose output.
* Fortran: Add infrastructure to detect compiler version (#15372)Brad King2015-02-191-0/+41
| | | | | | | | Fortran does not offer syntax to compose a string literal at preprocessing time from numeric compuations. Instead encode each digit of each component as a separate INFO string and compose them in CMake code after extraction. Support MAJOR, MINOR, PATCH, and TWEAK components with up to 8 digits each.
* Avoid if() quoted auto-dereferenceBen Boeckel2014-10-201-4/+4
| | | | | | | When testing CMAKE_<LANG>_COMPILER_ID values, do not explicitly dereference or quote the variable. We want if() to auto-dereference the variable and not its value. Also replace MATCHES with STREQUAL where equivalent.
* Replace MATCHES ".+" tests with NOT STREQUAL ""Rolf Eike Beer2014-04-141-1/+1
|
* Remove .* expressions from beginning and end of MATCHES regexsRolf Eike Beer2014-04-141-3/+3
| | | | | | | | | All these expressions work the same: "foo" ".*foo.*" "^.*foo.*$" This assumes that the "Intel*" expressions were meant to be "Intel.*".
* Xcode: Convert forced CMAKE_<LANG>_COMPILER to full path if possibleBrad King2014-03-101-0/+1
| | | | | | | During cross-compiling the toolchain file may use CMakeForceCompiler to force a compiler setting. When using the Xcode generator try to convert it to a full path by searching the PATH as is done for the Makefile generators.
* CMakeDetermine*Compiler: Factor out search for compiler in PATHBrad King2014-03-101-25/+1
| | | | | Factor out a _cmake_find_compiler_path helper macro to avoid duplication of the search for a full path to the compiler.
* CMakeDetermine*Compiler: Fix typo 'lile' => 'like'Stephen Kelly2014-01-221-1/+1
|
* Drop use of configure_file IMMEDIATE optionDaniele E. Domenichelli2013-11-131-1/+1
| | | | | | Since commit 7d47c693 (Drop compatibility with CMake < 2.4, 2013-10-08) we no longer need to use the configure_file IMMEDIATE option to support compatibility modes less than 2.0.
* CMakeDetermine*Compiler: Remove temporary cache entryBrad King2013-10-241-1/+1
| | | | | | | | When the user or toolchain file sets CMAKE_<LANG>_COMPILER to a name without a path we use find_program with CMAKE_<LANG>_COMPILER_WITH_PATH to search for the tool. Remove the temporary cache entry afterward to avoid exposing it to projects. It is not set by other logic paths so no one should be using it.
* VS: Detect Intel Fortran compiler id and versionBrad King2013-10-181-4/+0
| | | | | | Teach CMakeDetermineCompilerId to use a .vfproj project file to build the Fortran compiler id source file under the Visual Studio generators.
* Determine C/CXX/Fortran compiler: fix indentationAlex Neundorf2013-03-141-10/+10
| | | | Alex
* Determine C/CXX/Fortran compiler: minor restructuringAlex Neundorf2013-03-141-3/+5
| | | | | | | No functional changes, only change the way the if()-condition works, to make it easier to add more cases. Alex
* CMakeDetermineFortranCompiler: add support for cross-compiling (#13379)Alex Neundorf2012-09-111-0/+26
| | | | | | | | This adds the same support code for cross compiling to CMakeDetermineFortranCompiler as there is already in the C and CXX versions of this file. Alex
* Make platform information files specific to the CMake versionBrad King2012-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | At the top of a build tree we configure inside the CMakeFiles directory files such as "CMakeSystem.cmake" and "CMake<lang>Compiler.cmake" to save information detected about the system and compilers in use. The method of detection and the exact results store varies across CMake versions as things improve. This leads to problems when loading files configured by a different version of CMake. Previously we ignored such existing files only if the major.minor part of the CMake version component changed, and depended on the CMakeCache.txt to tell us the last version of CMake that wrote the files. This led to problems if the user deletes the CMakeCache.txt or we add required information to the files in a patch-level release of CMake (still a "feature point" release by modern CMake versioning convention). Ensure that we always have version-consistent platform information files by storing them in a subdirectory named with the CMake version. Every version of CMake will do its own system and compiler identification checks even when a build tree has already been configured by another version of CMake. Stored results will not clobber those from other versions of CMake which may be run again on the same tree in the future. Loaded results will match what the system and language modules expect. Rename the undocumented variable CMAKE_PLATFORM_ROOT_BIN to CMAKE_PLATFORM_INFO_DIR to clarify its purpose. The new variable points at the version-specific directory while the old variable did not.
* Xcode: Detect the compiler id and tool locationBrad King2012-08-221-0/+2
| | | | | | | | Configure a hand-generated Xcode project to build the compiler id source file since we cannot run the compiler command-line tool directly. Add a post-build shell script phase to print out the compiler toolset build setting. Run xcodebuild to compile the identification binary. Parse the full path to the compiler tool from the xcodebuild output.
* Re-order C/C++/Fortran compiler determination logicBrad King2012-08-221-88/+88
| | | | | | | | | | | | Re-organize CMakeDetermine(C|CXX|Fortran)Compiler.cmake to search for the compiler command-line tool only under generators for which it makes sense. For the Visual Studio generators we do not expect to find the compiler tool from the environment, nor would we use the result anyway. Furthermore, set CMAKE_${lang}_COMPILER_ID_TEST_FLAGS only when it has a chance to be used. Extract _CMAKE_TOOLCHAIN_LOCATION from the compiler path after running the compiler id step so in the future that step can help find the path to the compiler.
* Remove CMake-language block-end command argumentsKitware Robot2012-08-131-22/+22
| | | | | | | | | | | | | | | | | 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-100/+100
| | | | | | | | | | | | | | | | | 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
* Remove trailing whitespace from most CMake and C/C++ codeKitware Robot2012-08-131-9/+9
| | | | | | | | | | | | | | | | | Our Git commit hooks disallow modification or addition of lines with trailing whitespace. Wipe out all remnants of trailing whitespace everywhere except third-party code. Run the following shell code: git ls-files -z -- \ bootstrap doxygen.config '*.readme' \ '*.c' '*.cmake' '*.cpp' '*.cxx' \ '*.el' '*.f' '*.f90' '*.h' '*.in' '*.in.l' '*.java' \ '*.mm' '*.pike' '*.py' '*.txt' '*.vim' | egrep -z -v '^(Utilities/cm|Source/(kwsys|CursesDialog/form)/)' | egrep -z -v '^(Modules/CPack\..*\.in)' | xargs -0 sed -i 's/ \+$//'
* Prefer generic system compilers by default for C, C++, and FortranBrad King2012-08-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach CMake to prefer the system default compiler automatically when no compiler is specified. By default use "cc" for C, "CC" for C++, and "f95" for Fortran. Load a new Platform/<os>-<lang>.cmake module to allow each platform to specify for each language its system compiler name(s) and/or exclude certain names. Create Platform/(CYGWIN|Darwin|Linux|Windows)-CXX.cmake modules to specify "c++" as the system C++ compiler name for these platforms. On systems that use case-insensitive filesystems exclude C++ compiler names that are distinguished from C compiler names only by case. This will change the default compiler selection for existing build scripts that do not specify a compiler when run on machines with separate system and GNU compilers both installed in the PATH. We do not make this change in default behavior lightly. However: (1) If a given build really needs specific compilers one should specify them explicitly e.g. by setting CC, CXX, and FC in the environment. (2) The motivating case is to prefer the system Clang on newer OS X systems over the older GNU compilers typically also installed. On such systems the names "cc" and "c++" link to Clang. This is the first platform known to CMake on which "c++" is not a GNU compiler. The old behavior selected "gcc" for C and "c++" C++ and therefore chooses GNU for C and Clang for C++ by default. The new behavior selects GNU or Clang consistently for both languages on older or newer OS X systems, respectively. (3) Other than the motivating OS X case the conditions under which the behavior changes do not tend to exist in default OS installations. They typically occur only on non-GNU systems with manually-installed GNU compilers. (4) The consequences of the new behavior are not dire. At worst the project fails to compile with the system compiler when it previously worked with the non-system GNU compiler. Such failure is easy to work around (see #1). In short this change creates a more sensible default behavior everywhere and fixes poor default behavior on a widely-used platform at the cost of a modest change in behavior in less-common conditions.
* Factor common code out of CMakeDetermine(ASM|C|CXX|Fortran)CompilerBrad King2012-08-021-37/+6
| | | | | | | | | | | | | | | | | The compiler candidate list selection and search code for C, C++, ASM, and Fortran languages was duplicated across four modules. To look for compilers adjacent to already-enabled languages the C and CXX modules each used _CMAKE_USER_(C|CXX)_COMPILER_PATH and the ASM module used _CMAKE_TOOLCHAIN_LOCATION. Since commit 4debb7ac (Bias Fortran compiler search with C/C++ compilers, 2009-09-09) CMake prefers Fortran compilers matching the vendor and directory of an enabled C or C++ compiler. Factor out the common functionality among the four languages into a new CMakeDetermineCompiler module. Generalize the Fortran implementation so that all languages may each use the vendor and directory of the other languages that have already been enabled. For now do not list any vendor-specific names for C, C++, or ASM so that only the directory preference is used for these languages (existing behavior).
* detect "pgfortran" as PGI Fortran compiler (#12425)Rolf Eike Beer2012-02-081-4/+4
| | | | See http://www.pgroup.com/doc/pgiug.pdf, page xviii.
View Lorry Controller Status