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.
If this option is enabled, the test step is created with the
EXCLUDE_FROM_MAIN option, and if TEST_BEFORE_INSTALL is enabled, the
install step does not depend on the test step.
This means that the test step is never executed, unless the test target
is explicitly created by calling ExternalProject_Add_StepTarget, or by
passing it with the STEP_TARGETS option, or with the EP_STEP_TARGETS
directory property.
The external project's build process may generate byproducts on which
other rules in the driving project's build later depend. Provide a way
for the driving project to specify what byproducts it expects to be made
available by the custom commands that drive the external project.
3c497f11 Help: Add notes for topic 'ExternalProject_UPDATE_DISCONNECTED'
aba5cec6 ExternalProject: Add unit tests for UPDATE_DISCONNECTED
3f606fa7 ExternalProject: Add UPDATE_DISCONNECTED option
c0b749cf ExternalProject: Always add a command to a step
The change in commit v3.1.0-rc1~85^2 (ExternalProject: Fix download
retry logic, 2014-09-13) dropped the file(DOWNLOAD) EXPECTED_HASH
argument. This prevents file(DOWNLOAD) from skipping the download if
the output file already exists with the proper hash. Restore this check
with explicit code in the download script.
Reported-by: Ruslan Baratov <ruslan_baratov@yahoo.com>
If UPDATE_DISCONNECTED is set, the update step is not executed
automatically when building the main target. The update step can still
be added as a step target and called manually. This is useful if you
want to allow to build the project when you are disconnected from the
network (you might still need the network for the download step).
This is disabled by default.
The directory property EP_UPDATE_DISCONNECTED can be used to change
the default value for all the external projects in the current
directory and its subdirectories.
Some generators (i.e. Xcode) will not generate a file level target if
no command is set, and therefore the dependencies on this target will
be broken.
This patch sets an empty echo command that does nothing to avoid this
issue.
The ExternalProject_Add_StepDependencies function add some dependencies
for some external project step.
The syntax is:
ExternalProject_Add_Step_Dependencies(<name> <step> [target1 [target2 [...]]])
This function takes care to set both target and file level dependencies,
and will ensure that parallel builds will not break.
It should be used instead of add_dependencies() when adding a dependency
for some of the step targets generated by ExternalProject. See also:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/8680/focus=8926
When adding step targets using ExternalProject_Add_StepTargets, the
STEP_TARGETS argument or the EP_STEP_TARGETS property, ExternalProject
sets all the dependencies for the main project to that target. Due to
this, the update target cannot be used without downloading and building
all the dependencies.
In order to be able to add step targets that do not depend on other
external projects, this patch adds:
* An optional "NO_DEPENDS" argument to the
ExternalProject_Add_StepTargets function. If this argument is set,
then no dependencies are set for the target (file dependencies will
still be set).
* A new argument INDEPENDENT_STEP_TARGETS to the ExternalProject_Add
function and a new directory property EP_INDEPENDENT_STEP_TARGETS that
behave like STEP_TARGETS and EP_STEP_TARGETS, but cause the
ExternalProject_Add_StepTargets to be called with the NO_DEPENDS
argument.
This argument allows to set default arguments that are written in the
initial cache file, but that are not forced, and therefore allows the
user to change these values later (CMAKE_ARGS and CMAKE_CACHE_ARGS
always overwrite the values).
Also add some documentation to explain the differences between these 3
arguments.
Extend ExternalProjectLocal test to cover CMAKE_CACHE_DEFAULT_ARGS.
Convert ExternalProject module documentation to use explicit markup
blocks for each command. Enumerate command options with definition
lists instead of a literal block. This will allow more detail to be
added later. Also fix the logic that parses options out of the
documentation to be aware of the new layout.
Use a bracket comment to hold the documentation instead of a block of
line comments. This will make further updates easier. Also fix the
logic that parses options out of the documentation to be aware of the
new layout.
Fix the CMP0054 warning:
CMake Warning (dev) at .../Modules/ExternalProject.cmake:242 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
Quoted keywords like "COMMAND" will no longer be interpreted as keywords
when the policy is set to NEW. Since the policy is not set the OLD
behavior will be used.
Call Stack (most recent call first):
.../Modules/ExternalProject.cmake:1938 (_ep_parse_arguments)
CMakeLists.txt:5 (ExternalProject_Add)
by avoiding a reference to "${key}" or "COMMAND" in quotes.
be6a555d Tests: Test setting a generator platform in a toolchain file
d506fee8 Tests: Use -A option to pass generator platform selection
11c9ddd6 ExternalProject: Use -A option to pass generator platform
29bd843e CTest: Use -A option to pass generator platform selection
eb7d8156 cmake: Add -A option to specify a generator platform