Previously our EnforceConfig script that loads at test-time would only
enforce a non-empty CTEST_CONFIGURATION_TYPE for CMake 2.6.2 and lower.
Now we simply always enforce use of a configuration, and select one of
the configurations that was built if none is given.
This is necessary to run tests like CMake.Install that need to know the
configuration with which CMake was built.
We create option CMake_TEST_INSTALL to enable a new CMake.Install test.
It tests running the "make install" target to install CMake itself into
a test directory. We enable the option by default for dashboard builds.
We configure an EnforceConfig.cmake script to load at CTest time.
Previously we loaded it from Tests/CTestTestfile.cmake, but now we load
it from the top level so it applies to all tests.
CMake 2.8.0 and below use the EXECUTABLE_OUTPUT_PATH setting from the
top-level CMakeLists.txt file to compute the location of the "cmake"
target for the special case of installing cmake over itself.
The commit "Clean up CMake build tree 'bin' directory" moved the setting
of EXECUTABLE_OUTPUT_PATH that affects the "cmake" target into the
Source subdirectory. This broke the special-case lookup in the top
level. We fix it by setting EXECUTABLE_OUTPUT_PATH at the end of the
top-level CMakeLists.txt file. Now that we use add_subdirectory to
process the subdirectories in order, this setting does not affect the
subdirectories. Thus we fix installation while preserving the clean
build tree 'bin' directory intended by the above-mentioned commit.
We switch CMake's own top-level CMakeLists.txt file to use the modern
add_subdirectory() command instead of the old subdirs() command. This
enables in-order processing.
CMake has a special case for the "make install" target when building
CMake itself. We use the just-built CMake to install itself since an
existing CMake installation cannot replace itself (at least on Windows).
We simplify the code that computes the location of the CMake binary by
taking advantage of existing generator support for target lookup. This
will make it robust to any changes in CMake's own CMakeLists.txt files
in the future.
Some fixes for including Qt frameworks.
Remove extra "QtGui.framework" so its not Contents/Frameworks/QtGui.framework/QtGui.framwork/... anymore.
Also include QtGui Resource folder, so a Cocoa/Qt based cmake-gui app works.
Xcode 2.x forgets to create the target output directory before linking
the individual architecture pieces of a universal binary for the target
CMakeLibTests. Then it passes the directory to -L and -F options when
linking the and warns that the directory does not exist. We work around
the problem by using a pre-build rule on the target to create the output
directory.
CTest filters the output from tools and tests to ensure that the XML
build/test result documents it generates have valid characters.
Previously we just converted all non-ASCII bytes into XML-escaped
Unicode characters of the corresponding index. This does not preserve
tool output encoded in UTF-8.
We now assume UTF-8 output from tools and implement decoding as
specified in RFC 3629. Valid characters are preserved, possibly with
XML escaping. Invalid byte sequences and characters are converted to
human-readable hex values with distinguishing tags. See issue #10003.
We re-arrange EXECUTABLE_OUTPUT_PATH settings to avoid putting utility
and test executables in the 'bin' directory of the build tree. This
makes the directory look like that in the installation tree, except that
on multi-configuration generators we still use a per-config
subdirectory.
The commit "Cleanup regular expressions" removed real include filter
expressions and replaced them with lines like
INCLUDE_REGULAR_EXPRESSION("^.*$")
that do no filtering. We simplify the change by removing the lines
altogether.
KWSys should not set variables outside its namespace. It can honor the
EXECUTABLE_OUTPUT_PATH set by a host project, but tere is no need for it
to set a default in the host project cache.
The DumpDocumentation executable and some supporting code and tests were
completely unused by CMake. Generation of documentation is done by the
individual executables with --help* options. In this commit we simply
remove the unused code, executable, and test.
Previously this module gave only very brief documentation. We extend
the module's documentation to describe CTestConfig.cmake, interaction
with dashboard scripts, and the CTEST_USE_LAUNCHERS option.
We remove the shared library compile/link flags "-fPIC" and "-shared"
because they are not provided by all compilers on Linux. This allows us
to drop code from the Linux-XL-*.cmake files that erases the bad flags.
All other supported compilers already provide their correct flags for
Linux in their own platform information files.
We factor flags from Platform/Linux-PGI-Fortran.cmake into language
independent helper modules
Compiler/PGI.cmake
Platform/Linux-PGI.cmake
and invoke the macros from
Compiler/PGI-<lang>.cmake
Platform/Linux-PGI-<lang>.cmake
This enables general support for the PGI compilers.
The commit "Split GNU compiler information files" intended to move GNU
flags from the platform-wide Platform/SunOS.cmake module into
Platform/SunOS-GNU-<lang>.cmake
using a helper module Platform/SunOS-GNU.cmake to consolidate flags.
However, it accidentally put Fortran flags in the C language module and
left out the Fortran module altogether. This fixes those mistakes.
Several platform-wide linker flag variables are defined in
Modules/Platform/<os>.cmake files for C and then copied by the
Modules/CMake<lang>Information.cmake file for each language.
We now use this approach for the variables
CMAKE_EXE_EXPORTS_${lang}_FLAG
CMAKE_SHARED_LIBRARY_SONAME_${lang}_FLAG
CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS
to avoid duplication for multiple languages in each platform file.
The commit "Split GNU compiler information files" broke the settings of
CMAKE_SHARED_LIBRARY_CREATE_${lang}_FLAGS
CMAKE_SHARED_MODULE_CREATE_${lang}_FLAGS
and started using just "-shared" for them. This worked when tested on newer
Mac machines, but older ones really need "-dynamiclib" and "-bundle" (which are
the documented flags anyway).
The Intel Fortran plugin to VS defines VFFortranCompilerTool as the
compiler tool. This commit fixes generated projects to use that tool
for per-source settings instead of VCCLCompilerTool. We were already
using it for target-wide compiler settings.
This moves GNU compiler info on Windows into new-style modules
Platform/Windows-GNU-<lang>.cmake
using language-independent helper module
Platform/Windows-GNU.cmake
to define macros consolidating the information.