Previously CTest would drop dashboard submissions at public.kitware.com
on the PublicDashboard project if there was no configuration. The
server no longer supports forwarding to cdash.org, so there is no point
in this default. Furthermore, there should be no default at all because
it could leak information about proprietary projects that are not
configured correctly.
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.
CMakeSystemSpecificInformation.cmake into a separate file,
CMakeEclipseCDT4.cmake
-if CMAKE_EXTRA_GENERATOR is set, i.e. either CodeBlocks or KDevelop3 or
EclipseCDT4, load a matching cmake script file, which can do things specific
for this generator
- added such files for Eclipse, KDevelop and CodeBlocks, one thing they all
do is they try to find the respective IDE and store it in the
CMAKE_(KDEVELOP3|CODEBLOCKS|ECLIPSE)_EXECUTABLE variable.
This could be used by cmake-gui to open the project it just generated with
the gui (not sure this is possible with eclipse).
Alex
After extracting the tarball in a temporary directory we copy the tree
to the destination directory. The 'cmake -E copy_directory' command
does not preserve file timestamps, so we use file(COPY) instead.
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.
This fixes the get_configure_command_id function to not mistake
CONFIGURE_COMMAND values that run "cmake -P" or "cmake -E" for a CMake
project configuration. These values just help run scripts.
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 add_external_project function parses its arguments and puts them in
properties of the target it creates. This factors out implementation of
the behavior for use by other functions in the module.
The patch step runs parallel to the update step since it does not make
sense to have both. Configuration of the step requires specification of
a PATCH_COMMAND argument to add_external_project.
This rewrites the keyword/argument parsing and handling in the
AddExternalProject module to use arguments more literally:
- The strict keyword-value pairing is gone in favor of keywords with
arbitrary non-keyword values. This avoids requiring users to escape
spaces and quotes in command lines.
- Customized step command lines are now specified with a single
keyword <step>_COMMAND instead of putting the arguments in a
separate entry (previously called <step>_ARGS).
- Build step custom commands now use VERBATIM mode so that arguments
are correctly escaped on the command line during builds.
This creates global property RULE_MESSAGES which can be set to disbale
per-rule progress and action reporting. On Windows, these reports may
cause a noticable delay due to the cost of starting extra processes.
This feature will allow scripted builds to avoid the cost since they do
not need detailed information anyway. This replaces the RULE_PROGRESS
property created earlier as it is more complete. See issue #8726.
This creates global property RULE_PROGRESS which can be set to disbale
per-rule progress reporting. On Windows, progress reports may cause a
noticable delay due to the cost of starting an extra process. This
feature will allow scripted builds to avoid the cost since they do not
need detailed progress anyway. See issue #8726.
its system include directories. These are catched in CMakeSystemSpecificInformation.cmake
(only with the Eclipse generator) and then written by the Eclipse generator
in the Eclipse project file. This way Eclipse can find the standard headers
(#7585)
Not sure CMakeSystemSpecificInformation.cmake is the best place to do this.
Alex
