Commit Graph

45 Commits

Author SHA1 Message Date
Brad King 7195aca54f Make platform information files specific to the CMake version
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.
2012-08-24 10:52:23 -04:00
Brad King 965a69dcaa Xcode: Detect the compiler id and tool location
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.
2012-08-22 15:14:33 -04:00
Brad King b8b5c8342a Re-order C/C++/Fortran compiler determination logic
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.
2012-08-22 15:14:33 -04:00
Kitware Robot 9db3116226 Remove CMake-language block-end command arguments
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
2012-08-13 14:19:16 -04:00
Kitware Robot 77543bde41 Convert CMake-language commands to lower case
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
2012-08-13 14:19:16 -04:00
Kitware Robot 7bbaa4283d Remove trailing whitespace from most CMake and C/C++ code
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/ \+$//'
2012-08-13 14:18:39 -04:00
Brad King 7e58e5bb68 Prefer generic system compilers by default for C, C++, and Fortran
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.
2012-08-02 13:26:01 -04:00
Brad King 796e33734d Factor common code out of CMakeDetermine(ASM|C|CXX|Fortran)Compiler
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).
2012-08-02 11:33:18 -04:00
Rolf Eike Beer bb5f48fe99 detect "pgfortran" as PGI Fortran compiler (#12425)
See http://www.pgroup.com/doc/pgiug.pdf, page xviii.
2012-02-08 20:26:27 +01:00
Brad King 38aab37962 Set CMAKE_<lang>_COMPILER_ID for VS generators
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.
2011-09-02 08:56:01 -04:00
Brad King ac5b999fff Add Absoft Fortran compiler id and basic flags
Identification at preprocessing time depends on definition of __ABSOFT__
to be added in service pack V11.1.2 of the compiler.
2011-05-20 08:53:36 -04:00
Brad King 6f2482aa97 Merge topic 'intel-compiler-windows-info'
cd43636 Modernize Intel compiler info on Windows
58c73c4 Detect Fortran target architecture on Windows
2010-12-21 13:58:39 -05:00
Brad King 58c73c43f6 Detect Fortran target architecture on Windows
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.
2010-12-16 09:33:06 -05:00
Brad King 24cc3d4817 Recognize the NAG Fortran compiler
The Numerical Algorithms Group (NAG) Fortran compiler does not document
a preprocessor macro to identify it.  Check for identifying output using
the -V option.
2010-12-09 17:51:47 -05:00
Todd Gamblin 2cde67a781 Modules: Fix spelling 'To distributed' -> 'To distribute' 2010-08-09 08:48:31 -04:00
C. Bergström 36d850b87e Detect PathScale Fortran compiler tools
Include names pathf(90|95|2003) in the search for a Fortran compiler.
Also associate the names with PathScale for the vendor-specific search.
2010-04-26 13:31:52 -04:00
Brad King 11dcef910a Recognize the Compaq Fortran compiler
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.
2010-02-02 07:21:36 -05:00
Brad King 55275e017d New decision method to enable Fortran tests
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.
2009-12-10 12:16:38 -05:00
Brad King 3a666595c9 Convert CMake non-find modules to BSD License
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.
2009-09-28 11:46:51 -04:00
Brad King 4debb7ac69 Bias Fortran compiler search with C/C++ compilers
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.
2009-09-09 16:39:47 -04:00
Brad King ef756b96e4 ENH: Identify Fortran compilers with fixed format
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.
2009-06-25 08:45:19 -04:00
Bill Hoffman c224659b66 BUG: fix for #8089, fix rebuild with fortran and -D 2008-11-14 17:45:56 -05:00
Brad King 9211b0d234 ENH: Improvied compiler identification robustness
- 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
2008-02-25 09:23:14 -05:00
Brad King a75079d9e0 ENH: When detecting the compiler id try compiling only to an object file. 2008-02-11 17:00:54 -05:00
Brad King c12a7e388d BUG: When configuring compiler information files into the CMakeFiles 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. 2008-02-04 10:04:23 -05:00
Brad King bbbb2be765 BUG: When forcing the C and CXX compilers do not try to detect the ABI information. Cleanup configured language compiler info files by always using @ONLY. This addresses bug#6297. 2008-02-03 17:24:50 -05:00
Brad King 4b2218045d ENH: Add support to CMAKE_DETERMINE_COMPILER_ID macro to try building the id 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. 2008-01-07 10:27:28 -05:00
Alexander Neundorf d9bbc3f45f STYLE: fdcorrect comments about FC/CC
Alex
2007-05-18 09:16:07 -04:00
Brad King 8780da000a BUG: If the Fortran CompilerId source fails to compile it should not be a failure. It is only expected to work for Fortran90 compilers. 2007-05-18 09:08:49 -04:00
Alexander Neundorf 61d3444f93 ENH: merge CMake-CrossCompileBasic to HEAD
-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
2007-05-17 13:20:44 -04:00
Brad King 44ab336a0c ENH: Merging CompilerId updates from branch CMake-Modules-CompilerId to the main tree. Changes between CMake-Modules-CompilerId-mp1 and CMake-Modules-CompilerId-mp2 are included. 2007-05-03 08:24:32 -04:00
Bill Hoffman 086da498d4 ENH: remove df because df is a unix utilitiy 2007-02-21 10:03:11 -05:00
Bill Hoffman b8eede3b19 BUG: fix for bug 3950 add support for df compiler on windows 2007-02-20 16:43:32 -05:00
Brad King 7001a88a74 BUG: Search for the compiler only once and store a full path to it in the 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. 2006-08-29 13:59:15 -04:00
Ken Martin 8e9a6beccc ENH: centralized locaiton of CMakeFiles setting 2006-06-14 12:28:32 -04:00
Bill Hoffman aa98e3647d ENH: fix more than one argument passed in to compilers via environment 2006-01-25 11:41:05 -05:00
Bill Hoffman b7fa820118 ENH: add documentation support for modules 2005-12-14 13:51:08 -05:00
Ken Martin c6b011e35e ENH: put cmake files intoa CMakeFiles subdir to clean up bin tree 2005-07-29 09:19:25 -04:00
Bill Hoffman b8b298104b ENH: make sure flags set in CC or CXX environment variables stay with the compiler 2005-07-20 15:44:55 -04:00
Bill Hoffman 7cef36c628 ENH: add the ability to generate custom commands for a language that is not supported by an IDE 2004-10-21 14:34:02 -04:00
Ken Martin 2e4264e0d1 ENH: do not check for gnu for visual studio 2004-09-15 10:32:28 -04:00
Bill Hoffman ca5e9e6415 ENH: try to find fortran compiler before adding the test 2004-08-26 16:34:06 -04:00
Bill Hoffman e803b32b89 Add a fortran test if there is a fortran compiler 2004-08-26 15:50:39 -04:00
Bill Hoffman 66a08c10e5 ENH: more uniform approach to enable language, one step closer to being able to enable a language without modifing cmake source code 2004-08-26 14:55:55 -04:00
Bill Hoffman 9655299f08 ENH: initial fortran support 2004-08-06 14:51:41 -04:00