Add a new SOURCE_SUBDIR option to ExternalProject_Add that allows
specifying the location of the CMakeLists.txt to use as the project root
relative to the SOURCE_DIR.
This is helpful for projects that have unusual layouts, or projects that
provide both a superbuild and project-only build depending on which
CMakeLists.txt is used.
Fixes: #15118
Do not consider a top-level `.DS_Store` file when deciding whether a
tarball contains exactly one directory whose contents should be used as
the resulting top-level of the extraction.
Fixes#16218.
Suggested-by: Patrice Kouame
While at it, refactor logic to consolidate the filename extraction
and verification into a single match.
Inspired-by: Ruslan Baratov <ruslan_baratov@yahoo.com>
GIT_VERSION_STRING is unset in _ep_write_gitupdate_script(), hence
git stash is not being called with the "--all" option, even if Git
is new enough to support this.
Move the content to a `ExternalProject-download.cmake.in` file and use
`configure_file` to generate the final script.
Retry logic was not working before because similar script trigger
FATAL_ERROR if 'file(DOWNLOAD ...)' exits with nonzero 'status_code'.
FATAL_ERROR makes the whole chain of commands stop and
'_ep_write_verifyfile_script' retry logic was not used in fact.
Default retry number set to 5 with pauses 0, 5, 5, 15, 60 seconds. Some
space left for future improvements if needed (90, 300, 1200=20min). Can
be controlled by user.
The purpose of the `update` step is to run an update on each build
(subject to `UPDATE_DISCONNECTED`). This is done for version-controlled
source directories. We should do it for a custom `UPDATE_COMMAND` too.
In particular, when `UPDATE_DISCONNECTED` is used we expect the
`skip-update` step to exist.
Since commit 272779ce (ExternalProject: Allow TLS_VERIFY for git clones,
2016-04-01) we pass the `-c http.sslVerify=false` option to `git clone`
even if no explicit `TLS_VERIFY` option was set. This changes behavior
because we used to use the default Git behavior by default. Revise the
logic to preserve the old default behavior by passing the new option
only if `TLS_VERIFY` was explicitly passed as `OFF`.
While at it, also honor `CMAKE_TLS_VERIFY` if the explicit `TLS_VERIFY`
option is not given.
Since commit v3.5.0-rc1~32^2~1 (ExternalProject: Simplify `cmake
--build` configuration passing, 2016-01-19) we use the `$<CONFIG>`
generator expression to generate the `cmake --build . --config <config>`
value for the default BUILD_COMMAND instead of the CMAKE_CFG_INTDIR
placeholder value provided by multi-config generators. However, some
projects have been abusing the old implementation detail by setting
CMAKE_CFG_INTDIR themselves to get a specific configuration. Those
projects should be updated to set their own BUILD_COMMAND to get
non-default behavior. Meanwhile we can be compatible with their
existing releases by detecting when CMAKE_CFG_INTDIR is not a
generator-provided placeholder and using its value instead.
Check CMAKE_CONFIGURATION_TYPES instead of CMAKE_CFG_INTDIR in order
to recognize multi-config generators. Then use $<CONFIG> to pass
the configuration value.
Unset CMAKE_MODULE_PATH before calling find_package(Git) to ensure we do
not get a project-provided FindGit module that may not provide the
GIT_VERSION_STRING that we need. We do not need to restore the value
explicitly because this occurs inside the _ep_add_download_command
function call scope.
Refactoring in commit v3.4.0-rc1~77^2~1 (ExternalProject: Use
GIT_VERSION_STRING instead of custom method, 2015-09-17) forgot
to update the variable name used in an error message.
By default Mercurial command "clone" will implicitly call "update" with
the "default" branch after downloading the cloned repository. However
ExternalProject_Add() always generates a second "update" command after
cloning with a tag which is either specified or "tip" (equivalent to
"default" by default). Therefore ExternalProject will first clone then
update to default branch then update to another specified branch if
provided. This leads to potentially very long clone operation (in
particular when the repository default branch contain subrepos) which
can lead to transaction abort triggered by the server.
Simply use "hg clone -U" to avoid the implicit update during clone.
Our following call to "hg update" will take care of updating anyway.
Added new USES_TERMINAL option to the ExternalProject_Add_Step
function. This option passes USES_TERMINAL to the underlying
add_custom_command call so that the Ninja console pool is used.
Also, corresponding new USES_TERMINAL_<step> options were added
to the ExternalProject_Add function.
Justification: if using Ninja with a CMake superbuild, it's often
desirable to limit the superbuild to ONE sub-Ninja process at a
time to avoid oversubscribing the CPU. Using the console pool also
makes it easy to monitor the progress of the sub-Ninja process.
Independent USES_TERMINAL_<step> arguments are passed to
ExternalProject_Add instead of one USES_TERMINAL argument that
controls everything. Users may wish to run some steps in parallel
but not others (e.g. parallelize configure but not build).
Honor the GIT_SUBMODULES option added by commit v3.0.0-rc1~92^2
(ExternalProject: Add option GIT_SUBMODULES, 2014-01-09) during the
'git submodule init' step to avoid initalizing all modules since we
are only going to update the specified subset anyway. This will
be useful for project repositories that have many submodules
(e.g. https://github.com/boostorg/boost).
Reviewed-by: Daniele E. Domenichelli <daniele.domenichelli@iit.it>
Use file(GENERATE) to write the logging wrapper scripts to evaluate
generator expressions. Use a per-config script names in case the
content varies by configuration.
Use file(GENERATE) to write the initial cache file so that we can
evaluate generator expressions. Use a per-config initial cache file
name in case the content varies by configuration.
The `binary_dir` variable is never set, so this is invalid. Instead, use
"." which all the other build commands use anyways. Also only set the
--config option if it is meaningful.
Within an existing build tree, if the stamp for a step already exists
when one activates the ALWAYS option, we still want it to always build.
Remove the step stamp file during CMake configuration to ensure it does
not exist when the ALWAYS option is enabled.