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
In order to shorten the download failure of ExternalProject download
steps, a download retry is only done when a recoverable network
error is encountered.
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.
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>
The known keywords for each function are obtained by scraping the
documentation for lines matching a particular regular expression. In
commit 8842a027 (ExternalProject: Improve documentation, 2017-07-09),
the docs were overhauled and the COMMAND docs subsequently matched the
regular expression when they shouldn't have. This made COMMAND appear as
a true keyword, which thwarted the special handling logic elsewhere for
the intended use of COMMAND arguments.
This commit contains a workaround for issue #17229 to force a dependency
of the patch step on the update step to ensure a predictable step order.
Fixes: #17198
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).
Brad King