7bf15e49a8 ExternalProject: Fix misleading git update output
b2496bf14c FetchContent: Populate directly without a sub-build
173daad58d ExternalProject: Move more internal commands out of main file
462e583267 ExternalProject: Switch download, update and patch to use _EP_ vars
0ccc8e340d ExternalProject: Provide ExternalProject_Add keywords through a macro
91e1015722 ExternalProject: Don't treat YES as a keyword
a1743ce1ef ExternalProject: Fix minor formatting error
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: scivision <michael@scivision.dev>
Merge-request: !9513
Revert commit cabad8a37f (ExternalProject: Always use $<CONFIG> for
source files, 2023-02-02, v3.27.0-rc1~550^2~3) and restore
Xcode-specific behavior intentionally preserved by commit c111d440ce
(ExternalProject: Express per-config step stamp file paths using CONFIG
genex, 2022-06-08, v3.24.0-rc1~15^2). Unfortunately we still do not
have a test case, so leave a comment to avoid reverting this.
Issue: #23645
Issue: #23652
The commands moved to shared_internal_commands.cmake
will soon be used directly by FetchContent, which cannot
always include the full ExternalProject.cmake file (e.g. it may
be used in CMake script mode).
Issue: #21703
This refactoring prepares for the download, update, and
patch steps being called directly from FetchContent instead
of always being in a sub-build. When there is no sub-build,
there will be no targets to read properties from. This commit
moves the information to _EP_... variables, which will always
be readable.
Issue: #21703
This allows things outside of ExternalProject to have access
to the list of supported keywords. This will be used by
FetchContent in an upcoming change.
Issue: #21703
This ultimately won't change behavior, since YES should never be listed
in the "keywords" argument. The original code looks like a bug though,
since YES satisfies the criteria for being interpreted as a keyword, and
there is logic to short-circuit on TRUE and FALSE. Add YES to that
condition to avoid any potential confusion.
5d33f41e23 ExternalProject: reword `LIST_SEPARATOR` to indicate what it *does*
611ffce98c ExternalProject: add an example of `LIST_SEPARATOR` usage
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9376
Also remove the (IMO) confusing suggestion to have ` ` as a separator as
it interferes with things like spaces in argument values (e.g., paths)
or generated arguments such as `-GUnix Makefiles`. The new example is
likely more common usage of the facility.
Add a `TLS_VERSION` option and honor `CMAKE_TLS_VERSION` variables.
Also map the version to Git options as we already do for `TLS_VERIFY`.
Issue: #25701
If a URL contains special characters like parentheses and a few others,
they would previously have caused a foreach() call that iterates over the
URLs to parse those special characters as separate, unquoted arguments.
They would then have effectively split the list of URLs at unexpected places.
Prepare the arguments for the foreach() call by using use bracket syntax
to robustly handle any URLs that do have unescaped special characters.
Issue: #25148
If we are given an empty string for URL, or we have a logic error that leads
to the file we download to being an empty string, we will now catch this at
CMake configure time instead of whenever the download is attempted at
build time.
ExternalProject_Add_StepDependencies() contained a foreach() loop that
had another foreach() loop inside it iterating over the same set of values
(the dependencies). This resulted in add_dependencies() calls that added
the same dependencies to the step target N^2 times. A single call to
add_dependencies() with the list of dependencies provides the necessary
relationships without the N^2 behavior, and it removes the inner foreach()
loop.
Xcode has been reported to not work at all with this when
ExternalProject projects share download files.
Revert commit 872daff159 (ExternalProject: declare byproducts for the
download step, 2023-09-21, v3.28.0-rc1~27^2) pending further
investigation.
Fixes: #25525
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
