Since commit 77543bde (Convert CMake-language commands to lower case,
2012-08-13) the CMakeVersion.cmake file contains lower-case 'set'
commands. Teach CMakeVersion.bash to replace the lower-case name
instead of the old upper-case 'SET'.
After conversion of Modules .cmake files to lower case the
FAIL_REGULAR_EXPRESSION for this test matched warnings in modules other
than the test line itself. Make the pass and fail regular expressions
specific to the file containing the lines they are testing.
This was missed by commit 7bbaa428 (Remove trailing whitespace from most
CMake and C/C++ code, 2012-08-13) which only removed trailing spaces,
not TABs.
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
7e58e5b Prefer generic system compilers by default for C, C++, and Fortran
796e337 Factor common code out of CMakeDetermine(ASM|C|CXX|Fortran)Compiler
b708f1a CMakeDetermine(C|CXX)Compiler: Consider Clang compilers
Since commit c198730b (Detect Watcom compiler version with its id,
2011-12-07) the CMAKE_(C|CXX)_COMPILER_VERSION variables are set for the
Watcom compiler. Use these in Windows-wcl386.cmake to set the old
WATCOM1* version variables. This avoids using the old EXECUTE_PROCESS
command which failed due to extra quotes anyway.
Multiple versions of Xcode may be installed in different locations.
Run "xcode-select --print-path" to detect the active Xcode location
and parse its Contents/version.plist file. Note that the Xcode.app
directory name may vary in developer versions.
This fix bug #0013451. The bug prevents theorerically relocatable RPM package
to be installed properly.
Signed-off-by: Eric NOULARD <eric.noulard@gmail.com>
In cmGlobalXCodeGenerator::Generate we generate a .xcodeproj for each
directory in the tree containing a project() command. First we
iteratively use SetGenerationRoot to add "ALL_BUILD" and other targets
to each project. This leaves "CurrentProject" set to the last project
when we invoke cmGlobalGenerator::Generate, which is not the same as the
top-level project if any subdirectories invoke the project() command.
When cmGlobalGenerator::Generate reaches CreateGeneratorTargets it
constructs cmGeneratorTarget and calls ComputeTargetObjects exactly once
per target. In this context the value of CurrentProject is undefined so
we cannot pass it to GetObjectsNormalDirectory. Use "$(PROJECT_NAME)"
instead so it will adapt automatically to each project.
Also teach Tests/ObjectLibrary to cover this case.
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.
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).
Brad King
Kitware Robot
David Cole
Andy Piper
Rolf Eike Beer
Zack Galbreath