If the --trust-server-cert option is given to svn without the
--non-interactive option, the command fails with an error.
Previously, --non-interactive was always added, but
b1c2cb0436 (ExternalProject: Make SVN interactive with
USES_TERMINAL_{DOWNLOAD,UPDATE}, 2022-05-06) changed
the behavior to only add it if the relevant USES_TERMINAL_...
option was set to true.
Fixes: #25197
Introduces `BUILD_JOB_SERVER_AWARE` option to `ExternalProject_Add` and
`JOB_SERVER_AWARE` to `ExternalProject_Add_Step`. When using an explicit
`BUILD_COMMAND` or `COMMAND`, the generated commands won't use `$(MAKE)`
thus failing to connect to the outer make's job server. These new
options enable explicit job server integration.
Co-authored-by: Brad King <brad.king@kitware.com>
Fixes: #16273
Use RST subsections for each major step of `ExternalProject_Add()`.
This makes finding options easier with less scrolling.
For example, finding important Download vs. Test options etc.
Fixes: #25129
`ExternalProject_Add` treats all keyword arguments as multi-valued.
FetchContent re-orders some keyword arguments w.r.t. unparsed arguments.
Add an internal keyword argument to separate the keyword values from
following unparsed arguments.
This was exposed by commit 550f63447d (ExternalProject/FetchContent:
Support relative remote URLs, 2023-04-21, v3.27.0-rc1~156^2) by adding
`GIT_REPOSITORY` to the set of re-ordered keyword arguments. This
caused its value to absorb following unparsed arguments.
Fixes: #25029
Git config options can be passed to git clone before or after the
"clone" keyword. If specified before, the config setting is only
applied to that command invocation. It acts to override the value
in the global or project defaults (the latter doesn't exist for clone).
When the config setting is passed after the "clone" keyword, it is
saved into the cloned repository's config and will persist for later
git operations. The existing implementation expected the latter
behavior, but put the config setting before the "clone" keyword
and therefore the setting was not persisting to the git update
step. Move it to after the "clone" keyword so that it will persist.
The submodule handling is different. There is no support for
doing a "git submodule update" with a "sticky" config setting.
Instead, you have to pass the setting with all such calls. The
existing implementation was doing this for the clone step, but
not the git update step. Add the config setting there as well
so that submodules also effectively have the sslVerify setting
persist to the update step too.
Fixes: #18948
When UPDATE_DISCONNECTED is true, create separate update_disconnected
and patch_disconnected targets which have ALWAYS set to false.
Make the configure step depend on patch_disconnected in this case too.
This ensures the configure, build, install and test steps are not
executed unnecessarily when updates are disconnected.
Make the update and patch commands depend on the details of those
steps. This ensures they are re-executed when any of those details
change, even if updates are disconnected.
Allow updates to occur even if UPDATE_DISCONNECTED is true, but don't
contact the remote in that case. If asked to update to a ref that isn't known
locally, that is now detected and causes a fatal error when updates are
disconnected. Previously, the build would have silently and erroneously
continued to use the old ref.
Fixes: #16419, #19703, #21146
The problem fixed by commit c0b749cf62 (ExternalProject: Always add a
command to a step, 2014-11-05, v3.2.0-rc1~402^2~3) may occur for an
empty `COMMAND ${touch}` too, so avoid specifying any `COMMAND` at all
if there is no touch command.
Teach `ExternalProject_Add` and `FetchContent_Declare` to resolve
relative remote URLs provided via `GIT_REPOSITORY`. Add policy
CMP0150 to maintain compatibility.
Fixes: #24211
Co-Authored-By: Craig Scott <craig.scott@crascit.com>
Revert commit 66b5d51f38 (ExternalProject: Install CMake projects
using 'cmake --install', 2022-09-08, v3.25.0-rc1~150^2).
It changed the ExternalProject install step command from:
cmake --build <dir> --target install --config <cfg>
to:
cmake --install <dir> --config <cfg>
The latter command no longer runs the external project build system
during the install step. We could consider using the commands:
cmake --build <dir> --target all --config <cfg>
cmake --install <dir> --config <cfg>
as the install step, but if `CMAKE_SKIP_INSTALL_ALL_DEPENDENCY` is
used in the external project, that can change semantics too.
Revert the original change pending further investigation on other ways
to support its motivating use case. Add a test covering the
previously-regressed use case.
Fixes: #24567
Issue: #23946
d4d1f85297 Help: Move a note about arguments and genexes into include file
968224484f Help: Drop unused `PROPERTY_GENEX` replace from `prop_tgt/INTERFACE_*` files
65457e4fae Help: Add _See Also_ sections to related CMake commands
c86ec79d07 Help: Use direct refs to genexes instead of ``$<GENEX-NAME>``
8c6274326d Help: Use CMake highlighting for command synopsis
c356a94512 Help: Use monospaced font for a genex name in a section title
f98c8707f4 Help: Use `code-block:: cmake` instead of `::` for sub-commands descriptions
2ba351ca4f Help: ``CMake`` → CMake
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !7873
Add an `INSTALL_BYPRODUCTS` option to `ExternalProject_Add` that can
be used to declare that files are `BYPRODUCTS` of the ExternalProject
install step.
This is often required by the Ninja generator to explicitly declare
dependencies. Previously, many users used `BUILD_BYPRODUCTS`, even if
their files were created by the install step, not the build step.
This commit essentially just copies the code for `BUILD_BYPRODUCTS`.
Fixes: #24120Fixes: #23056
Clarify that the `BUILD_BYPRODUCTS` and `BYPRODUCTS` options
in ExternalProject may also be required when using the Ninja
generator (as that's one of the primary reasons why you'd want to
use those options).
I've also mentioned that `add_custom_command` has additional
documentation on what `BYPRODUCTS` does.
Previously, the build directory was not explicitly specified. Instead, the
current working directory was assumed to be the build directory and the
source directory was passed as a positional argument. However, if the
source directory contained a CMakeCache.txt, it was treated as a binary
directory instead. For the scenario where a project is built in-source and
it calls ExternalProject_Add() with its own source directory but a different
build directory (e.g. to build itself with a different set of configure arguments),
this results in a build error.
Explicitly list both the source and build directories using the -S and -B options
respectively. This unambiguously sets both, avoiding the above problem.
Fixes: #24081
In some cases, `cmake --install .` implements additional semantics over
just `cmake --build . --target install`. For example, using the Xcode
"new build system" with `IOS_INSTALL_COMBINED` requires special support
from `cmake --install` beyond building the `install` target.
Fixes: #23946
The `BUILD_BYPRODUCTS` option causes the ExternalProject's `build` step
in `build.ninja` to have `restat = 1`, so its "always out-of-date"
status caused by `BUILD_ALWAYS` does not propagate to the `install`
step. Mark the latter step as explicitly always out-of-date too.
Fixes: #23820
The change to `_ep_add_mkdir_command` in commit 5fbac2bb24
(ExternalProject: Move inline scripts to separate files, 2022-01-22,
v3.23.0-rc1~101^2) did not account for the possibility that
`CMAKE_CFG_INTDIR` is `$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)`
instead of just the configuration name. Pass the value into the helper
script on the command line so that the native buildsystem placeholders
are evaluated.
Fixes: #23645
The ExternalProject module has long used the generator-specific
placeholder in the `${CMAKE_CFG_INTDIR}` variable to express per-config
stamp file paths in multi-config generators. Now that most generators
support generator expressions in custom command outputs, we can use
the `$<CONFIG>` genex instead.
In particular, this fixes cross-config `BUILD_BYPRODUCTS` with the Ninja
Multi-Config generator.
Fixes: #23595
- Rewrap docs and commands to 80 character width, as per
code guidelines.
- Reformat argument lists across multiple lines to improve
readability.
- Use consistent closing parentheses on multi-line calls.
- Clean up indenting.
BRIEF_DOCS and FULL_DOCS became optional as of edb5059216
(define_property(): Make BRIEF_DOCS and FULL_DOCS optional,
2022-01-18). Remove these options from the define_property()
calls, since they served no useful purpose. The canonical
documentation of those properties is in the RST docs at the top of
the file.
ExternalProject_Add() supports USES_TERMINAL_* flags to enable user
input for different steps. The Subversion download options ignored
these flags when checking out or updated a Subversion repo.
Fixes: #23348
Add the option to keep the current filestamps when extracting an
archive in ExternalProject_Add.
Enabling this option makes the behavior consistent with how
ExternalProject_Add is used when checking out code from revision
control instead of an archive.
Fixes: #22746
8abd714176 Help: Clarify that ENVIRONMENT test properties take ;-separated lists
02cf404ace Help: Add advice for dealing with semicolons in lists
c4117d9116 ExternalProject: Document that LIST_SEPARATOR works for CMAKE_ARGS too
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !7066
Since `CMAKE_ARGS` is used to construct the default `CONFIGURE_COMMAND`
for CMake-based external projects, the `LIST_SEPARATOR` option works for
it too.
This brings the patch step into line with all the others which already
had their own `USES_TERMINAL_<step>` keyword. All steps (including
patch) already have their own `LOG_<step>` keyword too, so the lack of
`USES_TERMINAL_PATCH` was inconsistent.
This makes the scripts easier to work on, since the separate files
don't require the extra level of escaping that the inlined code did.
This also means the scripts can be rendered with appropriate
syntax highlighting in IDEs, etc.
This is in preparation for moving more inline content to separate
scripts as well. Having them in a separate subdirectory is consistent
with other modules and will make them easier to find and work with.
This change was originally made in 404cddb7bb (ExternalProject:
Fix misuse of IS_NEWER_THAN in timestamp checks, 2021-02-21),
but was reverted by 57d442e182 (Revert ExternalProject and
FetchContent refactoring, 2021-03-10) due to regressions from
other changes. Reapply this fix on its own, since it is still valid.
When using a file system which only has second resolution timestamps,
there is a reasonably high likelihood of timestamps being the same.
The IS_NEWER_THAN test returns true when timestamps are the same,
so don't redo downloads when they match exactly.
1cb65e680d (ExternalProject: Prevent the noisy detached head
messages on checkout, 2021-01-17) unconditionally added the advice.detachedHead
git config setting, but it requires git 1.7.7 or later. Since it isn't fatal to not
have it, just noisier, only add it when it is supported.
Fixes: #22206
Refactoring of the ExternalProject and FetchContent modules moved
the commands into CMake scripts. This broke custom commands that
used shell redirection or special build tool variables of the form
$(MakeVar). Undo the sequence of commits that performed this
refactoring and follow-up fixes associated with it.
The following commits are reverted by this change:
4f3d1abbb4 (ExternalProject: Refactor pre-configure steps to support
no-target uses, 2021-02-05)
17e5516e60 (FetchContent: Invoke steps directly and avoid a separate
sub-build, 2021-01-29)
bd876f3849 (FetchContent: Restore patch command support,
2021-02-18)
404cddb7bb (ExternalProject: Fix misuse of IS_NEWER_THAN in
timestamp checks, 2021-02-21)
b0da671243 (FetchContent: Don't update timestamps if files don't
change, 2021-02-18)
Fixes: #21892
The refactoring in 17e5516e60 (FetchContent: Invoke steps directly and
avoid a separate sub-build, 2021-01-29) uses a different way of writing
out the step scripts and updating time stamps when steps are executed.
That inadvertently always wrote out the scripts for custom commands,
even when the contents didn't change. This caused their timestamp to
always be updated, resulting in those steps always being seen as
out-of-date and needing to be re-executed.
The way timestamps were checked to determine whether to re-execute
a step also did not adequately account for file systems which only have
second-resolution timestamps. The IS_NEWER_THAN if condition also
returns true when timestamps are the same, so one needs to use the
negative form to get a true "is newer than" test.
ExternalProject is not susceptible to this problem because it uses
file(GENERATE) to write out the script files and that only updates the file's
timestamp if the contents change. It also mostly leaves timestamp
checking to the build tool.
The refactoring in 17e5516e60 (FetchContent: Invoke steps directly and
avoid a separate sub-build, 2021-01-29) contained a typo which resulted
in any PATCH_COMMAND being ignored. Fix the typo and add a test case
that would have caught the regression.
The cost of setting up and executing a separate sub-build to do the
download, update and patch steps required for FetchContent population
can be significant with some platforms and CMake generators. Avoid the
sub-build altogether by invoking the step scripts directly.
Previously, if no generator was set (e.g. population was being done in
script mode), a generator needed to be available on the default PATH.
Since we no longer use a sub-build, this restriction is also now gone.
Fixes: #21703
The mkdir, download, update and patch steps are used by
FetchContent during the configure phase of the main build. Because
these steps need a target, this has so far required a sub-build to be
set up. The changes here factor out the preparation of the scripts
from the creation of the targets, allowing future work to leverage these
steps without a sub-build (see #21703).
As part of the refactoring, some rationalisation of the stamp files,
repository info files and script names was done to make things more
consistent between download methods and step implementations.
Every download method now records its own specific repository info
in a file and that file is a dependency of the download step. The source
directory is also written to that file, so if the SOURCE_DIR changes, the
download will be retriggered (the existing implementation fails in this
scenario). Each download method now also has just one driver script
that implements the whole step (it may pull in other scripts to do its
task though). The patch step gained support for USES_TERMINAL as
a result of generalising the implementation for custom commands.
Fixes: #21748
