Also fix .bz2 extension to be .tar.bz2 since we only support compressed
tarballs and not plain compressed files.
Suggested-by: Nils Gladitz <nilsgladitz@gmail.com>
Suggested-by: Rolf Eike Beer <eike@sf-mail.de>
In commit v3.0.0-rc1~103^2~3 (ExternalProject: Reattempt download when
verification fails, 2014-01-15) a reference to ${CMAKE_COMMAND} was
added to generate a reference to the CMake command in a cmake script.
Escape the '$' so that the literal variable reference appears in the
script instead of writing the path to the current cmake. This is
necessary when the path to CMake contains spaces or other characters
special to CMake syntax.
The matches have already been calculated and can simply be taken from
CMAKE_MATCH_n variables. This avoids multiple compilations of the same or very
similar regular expressions.
When adding a new external project, the "all" target will depend on
this.
This option allows one to add an external project will not be executed
when the "all" target is executed.
The reason for this is that an external project could be useful, for
example, only for running tests, and therefore not necessary during
the build.
When adding a new step using ExternalProject_Add_Step, the main target
will depend on this step.
This option allows one to add a step that will not be executed when the
main target for the external project is executed.
ExternalProject handles git remote branches by commit hash. Due to
this, the git repository ends in detached states, and local commits
are discarded.
Use "git rebase" for remote branches instead of "git checkout". If
there are uncommitted changes, use "git stash save/pop" to save changes
and restore them after the rebase. If any of these operations fails,
try to restore the original status and exit with a fatal error, asking
the user to resolve the conflicts manually.
This also makes the behaviour of ExternalProject using git more similar
to the svn version, and probably more likely to what the user expects
by setting GIT_TAG to a branch.
Teach ExternalProject_Add a new BUILD_ALWAYS option to skip using
the build step stamp file and execute the step on every build.
Extend the BuildDepends test with a case to cover this option.
When downloading an URL with ExternalProject, reattempt the download three
times if the file hash verification fails.
The re-attempt is limited to non-local URL's. The same download CMake script
is re-used after removing any file that resulted from the previous download
attempt. Up to three re-attempts are performed.
Manually revise the .rst format of the documentation. Use inline
literal quotes appropriately in paragraph text. Move the :: literal
block openers to the end of the preceding paragraphs. Convert the
command signature documentation and examples to cmake code-block
directives.
The VS IDE sets the environment variable VS_UNICODE_OUTPUT when
executing build rules in order to tell MS tools to report output through
a back door instead of through stdout/stderr. Unset this variable so
that CMake can capture or properly redirect all output from processes it
runs even when running inside a VS IDE build environment.
This generalizes the special cases fixed by commit 80d045b0 (When
GetPrerequisites.cmake runs dumpbin while running inside the VS IDE...,
2008-05-01) and commit 44aff73d (ExternalProject: Avoid bleed-through
output when logging, 2011-01-06), so drop special handling of
VS_UNICODE_OUTPUT in those instances.
We support multiple commands per external project step by using
the COMMAND keyword. Document this behavior and show an example.
While at it, document that shell operators and current working
directory behavior is not defined.
With
SVN_USERNAME ""
SVN_PASSWORD ""
in an ExternalProject_Add() call, the blank username and password
will be passed to the svn checkout/update step commands.
When the CMAKE_GENERATOR option is given to ExternalProject_Add, look
also for option CMAKE_GENERATOR_TOOLSET to select the value of the cmake
"-T" command-line flag. When no CMAKE_GENERATOR option is given
explicitly then use the current project's CMAKE_GENERATOR_TOOLSET (since
we already use its CMAKE_GENERATOR).
The ExternalProject_Add DEPENDS option adds two types of dependencies.
It adds a target-level build order dependency between the external
project target and the named targets. It also adds a file-level
dependency on the "done" stamp file of the named external project
targets. Targets not created by ExternalProject_Add have no such stamp
file and no _EP_STAMP_DIR property. Prior to commit d14c0243 (Refactor
repeated code into function, 2012-04-26) we unconditionally accepted an
empty stamp dir and generated a dependency on a non-existent file.
After that commit we generate an error that no stamp dir is set.
Skip the file-level dependency when the named dependency is not an
external project target in order to allow this use case. Teach the
ExternalProject test to cover the case.
In the current default update step for Git under the ExternalProject_Add
command, a 'git fetch' is always performed, followed by a 'git checkout' and
'git submodule update --recursive'. However, a 'git fetch' can be time
consuming and requires a network connection.
To save time, we look at the current checked out hash, and only perform the
fetch if required. This is performed in a CMake script so we can handle
the conditional logic in a cross platform manner.
Make the EXPECTED_HASH option take only a single value instead of two to
avoid handling sub-keyword arguments. This is also consistent with
URL_HASH in ExternalProject.
Some download URLs do not have the filename embedded in the url.
Add an interface to specify the local filename explicitly.
Suggested-by: James Goppert <james.goppert@gmail.com>
TLS has superseded SSL so rename the recently added file(DOWNLOAD) and
ExternalProject options using the newer terminology. Drop "CURLOPT"
from names because curl is an implementation detail.
This commit adds the ability to turn on and off ssl certificate
authority checking. It also adds the ability to specify a
certificate authority information file. This can be done
by setting global cmake variables CMAKE_CURLOPT_CAINFO_FILE
and or CMAKE_CURLOPT_SSL_VERIFYPEER in the project calling
ExternalProject_Add, or by passing those options to individual
ExternalProject_Add calls.
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.
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
Fix the build command when Ninja is the CMake Generator, but the
external project is created for a project that does not use CMake but
does use "make".
By tracking a stamp file within the git clone script itself.
Avoids a 2nd git clone operation after switching from Debug
to Release builds in Visual Studio, or vice-versa.
Add "private/internal-use-only" function _ep_get_step_stampfile
to get the name of the stamp file for a given step.
The functionality provided by this commit should be identical
to its parent commit.
In the case of git, only track the repository in the
repository info dependency tracking file. Not the tag.
The download step should only re-run if the repository changes.
The download step should NOT re-run if the tag changes.
The update step is an 'always' re-running step, and so should
already re-run, unless it's been eliminated by use of
UPDATE_COMMAND ""
Commit f67139ae added running a verify script in between running
the download and extract scripts. Since then, it has always been
missing the COMMAND keyword added in this commit.
It worked anyway (semi-accidentally) by running a command line like:
cmake -P script1.cmake cmake -P script2.cmake
CMake, when running -P scripts on the command line, runs them in order,
and apparently ignores spurious arguments in between (the middle "cmake"
in the above example) and so, all appeared to work as intended.
This commit adds the missing keyword and the commands that run are
now two separate sequential cmake invocations like:
cmake -P script1.cmake
cmake -P script2.cmake
...which was the original intent of commit f67139ae
When GIT_EXECUTABLE points at ".../Git/cmd/git.cmd" in an msysGit
installation we previously failed to detect the version number in a
subtle case. The "git.cmd" assumes 'chcp' is in PATH. It is typically
available at "C:\Windows\System32\chcp.com". On 64-bit Windows the File
System Redirector maps this location to "C:\Windows\SysWOW64\chcp.com"
for 32-bit processes. However, some Windows installations fail to
provide chcp.com at this path. Whenever git.cmd runs in a 32-bit
command shell, as it does under a 32-bit CMake binary, it reports
'chcp' is not recognized as an internal or external command,
operable program or batch file.
on stderr. Capture stderr separately so it does not affect parsing
of the version number.
See also msysGit issue 358:
http://code.google.com/p/msysgit/issues/detail?id=358
Note that FindGit prefers "git.cmd" over "git.exe" because it sets up
the proper HOME environment variable necessary for Git ssh connections
to work the same as they do from the Git bash prompt.
The previous commit added --non-interactive as a "side effect"
of turning on SVN_TRUST_CERT. While reviewing that commit, we
decided all ExternalProject svn usage should be non-interactive.
That way, if there's any sort of problem, svn will return an
error right away rather than hang forever waiting for input...
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".
Brad King
Daniele E. Domenichelli
Rolf Eike Beer
Gereon Kremer
Matt McCormick
Kitware Robot
Bill Hoffman
David Cole
Peter Collingbourne