cmCTestScriptHandler, but have it load the new script CTestScriptMode.cmake
-> that makes it more flexible, also add a simple test that the system name
has been determined correctly
Alex
This extends the ExportImport test. The Export project creates a C++
static library and exports it. Then the Import project links the
library into a C executable. On most platforms the executable will link
only if the C++ linker is chosen correctly.
This test creates a C executable that links to a C++ static library. On
most platforms the executable will not link unless the C++ linker is
chosen correctly.
This creates cmCTestHG to drive CTest Update handling on hg-based work
trees. Currently we always update to the head of the remote tracking
branch (hg pull), so the nightly start time is ignored for Nightly
builds. A later change will address this.
See issue #7879. Patch from Emmanuel Christophe. I modified the patch
slightly for code style, to finish up some parsing details, and to fix
the test.
This creates new module ExternalProject.cmake to replace the prototype
AddExternalProject.cmake module. The interface is more refined, more
flexible, and better documented than the prototype.
This also converts the ExternalProject test to use the new module. The
old module will be removed (it was never in a CMake release) after
projects using it have been converted to the new module.
This test requires a long time on slower machines, so we need to extend
its timeout. It is an important test, so it does not fall under the
CMAKE_RUN_LONG_TESTS option. In the future we should try to shorten the
test by building simpler external projects.
The test needs to create a cvs repository with 'cvs init', but the CVSNT
client on Windows needs 'cvs init -n' to avoid administrator access.
Previously we required users to explicitly enable CTEST_TEST_UPDATE_CVS
to activate the test on Windows.
This teaches the test to use the '-n' option when necessary. Now we can
enable the test in all cases except when trying to use a cygwin cvs.exe
without cygwin paths.
If an executable marks symbols with __declspec(dllexport) then VS
creates an import library for it. However, it forgets to create the
directory that will contain the import library if it is different from
the location of the executable. We work around this VS bug by creating
a pre-build event on the executable target to make the directory.
The BZR xml output plugin can use some encodings that are not recognized
by expat, which leads to "Error parsing bzr log xml: unknown encoding".
This works around the problem by giving expat a mapping, and adds a
test. Patch from Tom Vercauteren. See issue #6857.
This creates cmCTestBZR to drive CTest Update handling on bzr-based work
trees. Currently we always update to the head of the remote tracking
branch (bzr pull), so the nightly start time is ignored for Nightly
builds. A later change will address this. Patch from Tom Vercauteren.
See issue #6857.
CMake directory removal code cannot remove content from read-only
directories (a separate bug which will be fixed). Therefore we should
not create them in the StringFileTest. This tweaks the file(COPY) call
to test not giving OWNER_WRITE to files rather than directories.
This property was left from before CMake always linked using full path
library names for targets it builds. In order to safely link with
"-lfoo" we needed to avoid having both shared and static libraries in
the build tree for targets that switch on BUILD_SHARED_LIBS. This meant
cleaning both shared and static names before creating the library, which
led to the creation of CLEAN_DIRECT_OUTPUT to disable the behavior.
Now that we always link with a full path we do not need to clean old
library names left from an alternate setting of BUILD_SHARED_LIBS. This
change removes the CLEAN_DIRECT_OUTPUT property and instead uses its
behavior always. It removes some complexity from cmTarget internally.
This creates target properties ARCHIVE_OUTPUT_NAME, LIBRARY_OUTPUT_NAME,
and RUNTIME_OUTPUT_NAME, and per-configuration equivalent properties
ARCHIVE_OUTPUT_NAME_<CONFIG>, LIBRARY_OUTPUT_NAME_<CONFIG>, and
RUNTIME_OUTPUT_NAME_<CONFIG>. They allow specification of target output
file names on a per-type, per-configuration basis. For example, a .dll
and its .lib import library may have different base names.
For consistency and to avoid ambiguity, the old <CONFIG>_OUTPUT_NAME
property is now also available as OUTPUT_NAME_<CONFIG>.
See issue #8920.
The file(INSTALL) command has long been undocumented and used only to
implement install() scripts. We now document it and provide a similar
file(COPY) signature which is useful in general-purpose scripts. It
provides the capabilities of install(DIRECTORY) and install(FILES) but
operates immediately instead of contributing to install scripts.
This extends the Preprocessor test to put spaces in the value of a
definition that is not a quoted string. In particular this tests that
VS6 supports values with spaces if they do not have '"', '$', or ';'.
See issue #8779.
Previously we rejected all preprocessor definition values containing
spaces for the VS6 IDE generator. In fact VS6 does support spaces but
not in combination with '"', '$', or ';', and only if we use the sytnax
'-DNAME="value with spaces"' instead of '-D"NAME=value with spaces"'.
Now we support all definition values that do not have one of these
invalid pairs. See issue #8779.
This creates cmCTestGIT to drive CTest Update handling on git-based work
trees. Currently we always update to the head of the remote tracking
branch (git pull), so the nightly start time is ignored for Nightly
builds. A later change will address this. See issue #6994.
The add_external_project function separates its arguments with ';'
separators, so previously no command line argument could contain one.
When specifying CMAKE_ARGS, some -D argument values may need to contain
a semicolon to form lists in the external project cache.
This adds add_external_project argument LIST_SEPARATOR to specify a list
separator string. The separator is replaced by ';' in arguments to any
command created to drive the external project. For example:
add_external_project(...
LIST_SEPARATOR ::
CMAKE_ARGS -DSOME_LIST:STRING=A::B::C
...)
passes "-DSOME_LIST:STRING=A;B;C" to CMake for the external project.
Linking to a Windows shared library (.dll) requires only its import
library (.lib). This teaches CMake to recognize SHARED IMPORTED library
targets that set only IMPORTED_IMPLIB and not IMPORTED_LOCATION.
CVS clients recognize file modifications only if a file's timestamp is
newer than its CVS/Entries line. This fixes intermittent failure of the
test on filesystems with low timestamp resolution by delaying before
creating a local modification.
This creates function 'add_external_project_step' to centralize creation
of external project steps. Users may call it to add custom steps to
external project builds.
The value of CMAKE_CURRENT_LIST_FILE is supposed to be the list file
currently being executed. Before macros were introduced this was always
the context of the argument referencing the variable.
Our original implementation of macros replaced the context of command
arguments inside the macro with that of the arguments of the calling
context. This worked recursively, but only worked when macros had at
least one argument. Furthermore, it caused parsing errors of the
arguments to report the wrong location (calling context instead of line
with error).
The commit "Improve context for errors in macros" fixed the latter bug
by keeping the lexical context of command arguments in macros. It broke
evaluation of CMAKE_CURRENT_LIST_FILE because the calling context was no
longer preserved in the argument referencing the variable. However,
since our list file processing now maintains the proper value of
CMAKE_CURRENT_LIST_FILE with dynamic scope we no longer need the context
of the argument and can just evaluate the variable normally.
The add_definitions() command and COMPILE_DEFINITIONS dir/tgt/src
properties support preprocessor definitions with values. Previously
values were not supported in the VS6 generator even though the native
tool supports them. It is only values with spaces that VS6 does not
support. This enables support and instead complains only for values
with spaces. See issue #8779.
Bill Hoffman
Brad King
Alexander Neundorf
David Cole
Ken Martin