summaryrefslogtreecommitdiffstats
path: root/Modules/CMakeDetermineFortranCompiler.cmake
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Set CMAKE_<lang>_COMPILER_ID for VS generatorsBrad King2011-09-021-4/+1
| | | | | | | | | | | | | Currently the VS generators do not support Intel C/C++ .icproj files and the MS tools do not include a Fortran compiler. Therefore we can always set the C and CXX compiler IDs to "MSVC" and the Fortran ID to "Intel". This fixes a regression in support for the Intel Fortran compiler under the VS plugin introduced by commit cd43636c (Modernize Intel compiler info on Windows, 2010-12-16). The commit moved the compiler information into platform files that only load when the proper compiler id is set. It worked for the NMake Makefiles generator but not for the VS IDE generator because it did not set the compiler id.
* Add Absoft Fortran compiler id and basic flagsBrad King2011-05-201-1/+2
| | | | | Identification at preprocessing time depends on definition of __ABSOFT__ to be added in service pack V11.1.2 of the compiler.
* Merge topic 'intel-compiler-windows-info'Brad King2010-12-211-0/+4
|\ | | | | | | | | | | cd43636 Modernize Intel compiler info on Windows 58c73c4 Detect Fortran target architecture on Windows
| * Detect Fortran target architecture on WindowsBrad King2010-12-161-0/+4
| | | | | | | | | | | | | | 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.
* | Recognize the NAG Fortran compilerBrad King2010-12-091-0/+3
|/ | | | | | The Numerical Algorithms Group (NAG) Fortran compiler does not document a preprocessor macro to identify it. Check for identifying output using the -V option.
* Modules: Fix spelling 'To distributed' -> 'To distribute'Todd Gamblin2010-08-091-1/+1
|
* Detect PathScale Fortran compiler toolsC. Bergström2010-04-261-2/+5
| | | | | Include names pathf(90|95|2003) in the search for a Fortran compiler. Also associate the names with PathScale for the vendor-specific search.
* Recognize the Compaq Fortran compilerBrad King2010-02-021-0/+5
| | | | | | | | | | The compiler documents symbols _DF_VERSION_ and _VF_VERSION_ but they do not seem to be available to the preprocessor. Instead we add a vendor query table entry for Compaq. Running "f90 -what" produces Compaq Visual Fortran Optimizing Compiler Version ... This clearly identifies the compiler.
* New decision method to enable Fortran testsBrad King2009-12-101-3/+0
| | | | | | | | | | CMake does not enable Fortran for its own build, but it needs to find a Fortran compiler to know if it is possible to enable Fortran tests. Previously we searched for a hard-coded list of Fortran compilers which was duplicated from the CMakeDetermineFortranCompiler.cmake module. We now run CMake on a small test project that enables the Fortran language and reports the compiler it found. This represents a more realistic check of whether the Fortran tests will be able to find a compiler.
* Convert CMake non-find modules to BSD LicenseBrad King2009-09-281-0/+13
| | | | | | | 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.
* Bias Fortran compiler search with C/C++ compilersBrad King2009-09-091-0/+35
| | | | | | | | | When CMAKE_Fortran_COMPILER and ENV{FC} are not defined CMake searches for an available Fortran compiler. This commit teaches the search code to look for compiler executables next to the C and C++ compilers if they are already found. Furthermore, we bias the compiler executable name preference order based on the vendor of the C and C++ compilers, which increases the chance of finding a compatible compiler by default.
* ENH: Identify Fortran compilers with fixed formatBrad King2009-06-251-1/+1
| | | | | | | | This enhances the Fortran compiler id detection by using a source that can compile either as free or fixed format. As long as the compiler knows it should preprocess the source file (.F) the identification can work. Even free-format compilers may try fixed-format parsing if the user specifies certain flags, so we must support both.
* BUG: fix for #8089, fix rebuild with fortran and -DBill Hoffman2008-11-141-1/+27
|
* ENH: Improvied compiler identification robustnessBrad King2008-02-251-1/+1
| | | | | | | | - Write a single source file into the compiler id directory - This avoid requiring the compiler to behave correctly with respect to include rules and the current working directory - Helps to identify cross-compiling toolchains with unusual default behavior
* ENH: When detecting the compiler id try compiling only to an object file.Brad King2008-02-111-0/+3
|
* BUG: When configuring compiler information files into the CMakeFiles ↵Brad King2008-02-041-1/+2
| | | | directory in the project build tree, use IMMEDIATE option for CONFIGURE_FILE explicitly. It is needed in case the user sets CMAKE_BACKWARDS_COMPATIBILITY to 2.0 or lower.
* BUG: When forcing the C and CXX compilers do not try to detect the ABI ↵Brad King2008-02-031-2/+3
| | | | information. Cleanup configured language compiler info files by always using @ONLY. This addresses bug#6297.
* ENH: Add support to CMAKE_DETERMINE_COMPILER_ID macro to try building the id ↵Brad King2008-01-071-1/+8
| | | | source more than once with different extra flags added to the compiler. Use the support to correctly identify the Intel Fortran compiler on windows which does not preprocess by default without special flags.
* STYLE: fdcorrect comments about FC/CCAlexander Neundorf2007-05-181-4/+5
| | | | Alex
* BUG: If the Fortran CompilerId source fails to compile it should not be a ↵Brad King2007-05-181-0/+1
| | | | failure. It is only expected to work for Fortran90 compilers.
* ENH: merge CMake-CrossCompileBasic to HEADAlexander Neundorf2007-05-171-9/+2
| | | | | | | | | | | | | | | | | | | | | | | | -add a RESULT_VARIABLE to INCLUDE() -add CMAKE_TOOLCHAIN_FILE for specifiying your (potentially crosscompiling) toolchain -have TRY_RUN() complain if you try to use it in crosscompiling mode (which were compiled but cannot run on this system) -use CMAKE_EXECUTABLE_SUFFIX in TRY_RUN(), probably TRY_RUN won't be able to run the executables if they have a different suffix because they are probably crosscompiled, but nevertheless it should be able to find them -make several cmake variables presettable by the user: CMAKE_C/CXX_COMPILER, CMAKE_C/CXX_OUTPUT_EXTENSION, CMAKE_SYSTEM_NAME, CMAKE_SYSTEM_INFO_FILE -support prefix for GNU toolchains (arm-elf-gcc, arm-elf-ar, arm-elf-strip etc.) -move ranlib on OSX from the file command to a command in executed in cmake_install.cmake -add support for stripping during install in cmake_install.cmake -split out cl.cmake from Windows-cl.cmake, first (very incomplete) step to support MS crosscompiling tools -remove stdio.h from the simple C program which checks if the compiler works, since this may not exist for some embedded platforms -create a new CMakeFindBinUtils.cmake which collects the search fro ar, ranlib, strip, ld, link, install_name_tool and other tools like these -add support for CMAKE_FIND_ROOT_PATH for all FIND_XXX commands, which is a list of directories which will be prepended to all search directories, right now as a cmake variable, turning it into a global cmake property may need some more work -remove cmTestTestHandler::TryExecutable(), it's unused -split cmFileCommand::HandleInstall() into slightly smaller functions Alex
* ENH: Merging CompilerId updates from branch CMake-Modules-CompilerId to the ↵Brad King2007-05-031-32/+52
| | | | main tree. Changes between CMake-Modules-CompilerId-mp1 and CMake-Modules-CompilerId-mp2 are included.
* ENH: remove df because df is a unix utilitiyBill Hoffman2007-02-211-1/+1
|
* BUG: fix for bug 3950 add support for df compiler on windowsBill Hoffman2007-02-201-1/+1
|
* BUG: Search for the compiler only once and store a full path to it in the ↵Brad King2006-08-291-14/+15
| | | | cache. This avoids problems with the case of locations in the PATH variable on Windows that change the compiler name when CMake is re-run. CMakeFiles/CMake*Compiler.cmake files should hold the full path to the compiler always.
* ENH: centralized locaiton of CMakeFiles settingKen Martin2006-06-141-3/+3
|
* ENH: fix more than one argument passed in to compilers via environmentBill Hoffman2006-01-251-1/+1
|
* ENH: add documentation support for modulesBill Hoffman2005-12-141-0/+1
|
* ENH: put cmake files intoa CMakeFiles subdir to clean up bin treeKen Martin2005-07-291-3/+3
|
* ENH: make sure flags set in CC or CXX environment variables stay with the ↵Bill Hoffman2005-07-201-0/+3
| | | | compiler
generated by cgit v0.12 at 2024-12-27 12:36:57 (GMT)