The ExternalProject module cannot be implemented in the Xcode "new build
system" without using CMP0114's NEW behavior. When configuring for that
build system, warn if the policy is not set to NEW and use NEW behavior
anyway.
`ExternalProject_Add_StepTargets` and `INDEPENDENT_STEP_TARGETS` have
some limitations and lack some sanity checks. They can cause confusing
build systems to be generated. The basic problems are:
* The notion of step independence is attached to the step target
rather than the step itself.
* The custom commands implementing the steps are duplicated in the
step targets and the primary targets. This can cause races.
It is also incompatible with the Xcode "new build system".
Fix this by introducing policy CMP0114 to change the way step target
dependencies are handled. Define independence from external
dependencies as a property of each individual step regardless of whether
there is a target for it. Add dependencies among the primary target and
the step targets such that each custom command only appears in one
target. When some steps are disconnected from the primary target, add
step targets for the steps commonly depended upon so that there is a
place to hold their custom commands uniquely.
Fixes: #18663
When updates are disconnected, don't depend on skip-update because that
target is always considered out of date. Depend directly on the patch target
instead because it already depends on the appropriate target regardless of
whether updates are disconnected or not. This in turn means nothing depends
on the skip-update target, so it has also been removed.
Relates: #21086
The skip-update target is always considered out-of-date. The change in
7249ba9677 (ExternalProject: Enforce that patch depends on update, 2020-04-03)
made the patch target depend on skip-update, which in turn made it
always out of date too. The patch command should only be re-run if the download
needs to be performed again where updates are disconnected.
Fixes: #21086
The optimization from commit 627fc5b44f (ExternalProject: Avoid
unnecessary checkout on clone, 2019-07-29, v3.16.0-rc1~325^2) triggers a
bug in the Git 2.20.x series that is not in older or newer versions.
Drop the optimization for that specific range of Git versions.
Fixes: #21009
GitLab now uses a `/-/` component between the `group/project` part of
the URL and the `{issues,merge_requests,tree}` part so that it can
support `group/subgroup/project` with arbitrary depth.
The refactoring exposed that the original implementation
was referring to an undefined variable src_name, which was
previously only used in error messages. This has been fixed
as part of the refactoring work.
Fixes: #20336
When looking at `list(FIND)` result, zero index is ignored due to
incorrect error handling, and users can't set dependencies on mkdir
step.
Fixes: #20605
In commit 5bc6230741 (ExternalProject: Option to turn off recursive
update of git submodules, 2019-10-16) we implemented the feature in the
clone script written by `_ep_write_gitclone_script` but not in the
update script written by `_ep_write_gitupdate_script`. Implement the
latter by factoring out a common helper to use in both places.
Fixes: #20335
The clone step checks out the cloned branch but is always followed by an
explicit checkout of the desired `GIT_TAG`. Tell `git clone` not to
check out.
-- When using default values for the external project forward GHS platform
variables so that the external project builds with the same tools as
the original project.
-- Fix issue with bad top level project when GHS_PRIMARY_TARGET is set but has
no value. In this case treat it as unset and use default value.
When GIT_SHALLOW is used, the '--depth 1 --no-single-branch'
arguments are add. It means that only branch names and tags
is downloaded to repository. Most Commit Hash is not working.
With this commit the documentation was updated, to describe
the limitation of GIT_SHALLOW.
Since commit 79410eeb1f (ExternalProject: Initialize Git submodules
recursively and on update (#16083), 2016-04-26, v3.6.0-rc1~105^2) our
`git submodule update` step uses the `--init` flag. This makes the
prior `git submodule init` unnecessary.
In commit b6f6cac378 (ExternalProject: add LOG_DIR option that allows
overriding of log location, 2018-10-12, v3.14.0-rc1~515^2~1) the log
directory got its own option. The intention was to fall back to the
stamp directory by default. However, the implementation actually only
falls back to the same default as the stamp directory and does not
consider a custom stamp dir.
Update the default log dir computation to fall back to whatever is the
final selection for the stamp dir.
Fixes: #19000
The output is only merged for a step if it is logging to file. This
option is ignored for steps that are logging normally.
A minor grammatical error has also been fixed as part of this change.
This option only has an effect if at least one of the other LOG_<step>
options is enabled. If an error occurs for a step which has logging to
file enabled, that step's output will be printed to the console. For
cases where a large amount of output is recorded, just the end of that
output may be printed to the console.
Most steps support the logging into a file but the patch command is a
notable exception. This commit adds the LOG_PATCH options that acts as
the other LOG_* options.
In some circumstances the user of ExternalProject may not desire the
split log files for stdout and stderr. In particular with a project has
many errors it can be difficult to correlate the output error with the
command that it resulted from.
This commit adds the LOG_MERGED_STDOUTERR option that when enabled
outputs into a unified <name>-<step>.log for each step. If disabled it
will default to the previous behaviour of <name>-<step>-out.log and
<name>-<step>-err.log.
In some situations it can be helpful to separate out the location of the
log files from the location of the stamp files. For instance if you have
a continuous integration that exposes the location where log files are
stored.
This commit adds an option that allows a user to override the default
behaviour of putting the log files in STAMP_DIR called LOG_DIR. The
previous behaviour of putting the log files into the STAMP_DIR applies
if LOG_DIR is not specified.
* The code snippets in the docs consist of CMake code mixed
with syntax definition punctuation like < > [ ] ... Therefore
a pure CMake lexer is inadequate. Here it is replaced by a
CMake syntax definition parser.
* Fixed syntax definition snippets in FindPkgConfig.cmake to
make best use of syntax highlighting. This source file is the
hardest to support because it contains comparison operators
<= = >=, which need special attention to avoid confusion
with the placeholder indicators <...>.
* Fixed syntax in execute_process.rst (there were unbalanced
brackets).
* Disabled syntax highlighting for long string examples in
cmake-language.7.rst.
* No highlighting of removed syntax in CMP0049
* To inspect the outcome of this patch, see e.g. the pages
* manual/cmake-buildsystem.7.html
* module/ExternalProject.html
* module/FindPkgConfig.html
which are particularly rich in complex code snippets.
Since in some situations, ExternalProject module may be included in
a sub-directory, functions will be available in the global scope but
local variables like "_ep_keywords_<keyword>" will not be defined, this
commit checks and reports an error indicating that the ExternalProject
module must be explicitly included before using any of the ExternalProject_*
functions that require the module's inclusion within the current scope
or above.
Co-authored-by: Pablo Hernandez <pablo.hernandez@kitware.com>
Co-authored-by: Craig Scott <craig.scott@crascit.com>
