Add options HG_REPOSITORY and HG_TAG to specify an external project
hosted in a Mercurial repository. Teach ExternalProject to clone the
repository and update from it. Extend the ExternalProject test to try a
Mercurial repository when hg is available.
The MSYS cvs tool interprets "c:/" as a "machine:" name for SSH. Detect
the MSYS cvs by looking for the string "msys" in the executable file
itself. Then convert the repo path to an MSYS path such as "/c/...".
Fix both the CTest.UpdateCVS and ExternalProject tests that use local
CVS repositories.
This test will fail to get a proper version number if running on a (e.g.
German) localized system because the regular expression used to match the
Subversion version output does not match. Instead of duplicating code just
remove the local test altogether and use the version that FindSubversion.cmake
already detects.
Which adds --non-interactive and --trust-server-cert to the svn
checkout and update command lines. This allows ExternalProject
clients to pull from an https:// based svn server even though
the server may not have a valid or trusted certificate.
Caveat emptor: I would NOT recommend using this except as a
short-term work-around. Rather, the server should have a valid,
trusted certificate, or the client should be using "http" instead
of "https".
Visual Studio Express editions do not support solution folders,
so default behavior should be as if USE_FOLDERS global property
is OFF.
Also, allow folder names to be the same as target names: internally,
use a prefix to distinguish folder GUIDs from target GUIDs. Add
a target and folder with the same name in the ExternalProject
test to exercise this code.
For CMake itself, provide a new option CMAKE_USE_FOLDERS that
defaults to ON so that Visual Studio users get a nicely organized
CMake project. Express edition users will have to turn off the
CMAKE_USE_FOLDERS option in order to build CMake in the VS Express
IDE.
This work was started from a patch by Thomas Schiffer.
Thanks, Thomas!
See the newly added documentation of the FOLDER target
property for details.
Also added global properties, USE_FOLDERS and
PREDEFINED_TARGETS_FOLDER. See new docs here, too.
By default, the FOLDER target property is used to organize
targets into folders in IDEs that have support for such
organization.
This commit adds "solution folder" support to the Visual
Studio generators. Currently works with versions 7 through
10.
Also, use the new FOLDER property in the ExternalProject
test and in the CMake project itself.
This commit introduces the ability to add custom targets
that correspond to individual ExternalProject steps.
The main motivation behind this new feature is to drive
sub-project based dashboard steps as external projects
with separate targets for update, configure, build and
test output. This makes it easy to construct a ctest -S
script to drive such a dashboard.
With no STEP_TARGETS defined, there are no additional
custom targets introduced, to minimize the chatter in
the target name space. Clients may define STEP_TARGETS
on a per-ExternalProject_Add basis, or at the directory
level by setting the EP_STEP_TARGETS directory property.
Optionally hide the output of each external project build step by
wrapping its command in a launcher script. Make output available in log
files instead. This simplifies the output of external project builds.
Use it from ExternalProject and the ExternalProject test's
CMakeLists file rather than having duplicate find_program calls.
Add logic so that we do not try to use *.cmd variants of git
programs when using the MSYS Makefiles generator. Should fix
the last remaining dashboard issue with the new ExternalProject
git support additions.
Also, correct minor problem regarding placement of the local git
repo during test execution. On clean builds, it was being placed
incorrectly because of the ../.. relative reference. Use an absolute
path to place the local git repo in the proper directory, and only
use the relative reference when referring to it.
Double quote executable names that may have spaces in them.
Do not run the new git portions of the test on machines that
have git < version 1.6.5 on them.
Add archives of these file types and add to the test
cases covered in the ExternalProject test.
Also add an "Example" directory in the Tests/ExternalProject
directory containing the canonical simplest example of
ExternalProject usage.
Improve FILE(DOWNLOAD ...):
- Add percent complete progress output to the FILE DOWNLOAD
command. This progress output is off by default to
preserve existing behavior. To turn it on, pass
SHOW_PROGRESS as an argument.
- Add EXPECTED_MD5 argument. Verify that the downloaded
file has the expected md5 sum after download is complete.
- Add documentation for SHOW_PROGRESS and EXPECTED_MD5.
When the destination file exists already and has the
expected md5 sum, then do not bother re-downloading
the file. ("Short circuit" return.)
Also, add a test that checks for the status output
indicating that the short circuit behavior is actually
occurring. Use a binary file for the test so that the
md5 sum is guaranteed to be the same on all platforms
regardless of "shifting text file line ending" issues.
Improve ExternalProject:
- Add argument URL_MD5.
- Add verify step that compares md5 sum of .tar.gz file
before extracting it.
- Add md5 check to download step, too, to prevent
unnecessary downloads.
- Emit a warning message when a file is not verified.
Indicate that the file may be corrupt or that no
checksum was specified.
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.
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 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 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 teaches AddExternalProject to run "$(MAKE)" for build and install
steps of CMake-based external projects when using a Makefile generator.
It allows the external project to participate in a parallel make invoked
on the superproject.
Brad King
Rolf Eike Beer
David Cole