A step with a custom command shouldn't be seen as out-of-date
just because the user re-runs configure with a different log level.
Previously, the log level was written directly to the step scripts,
but that meant the script changes if the user specifies a different
effective log level to the previous configure. Now we move the
log level detection into the script so that the script remains the
same no matter what log level the user asks for.
This was most noticeable with the PATCH step, since that always
uses a custom command when present. Changing the log level
would cause the PATCH step to re-run, which usually results in
an error because PATCH typically only expects to run once after
a DOWNLOAD. But the underlying problem would affect any step
with a custom command, not just PATCH.
Fixes: #28055
Introduce a mechanism (via the private and undocumented `ISSUE_WARNING`
option to the `cmake_policy` command) to allow built-in modules to issue
policy warnings. Update modules to use this.
This allows modules to issue policy warnings with the `CMD_POLICY`
diagnostic type, which is consistent with internally issued diagnostics.
This also tends to simplify the logic for issuing such warnings in much
the way the helpers introduced in the previous commit did for the C++
code.
Capture `execute_process` calls' `RESULT_VARIABLE`.
We don't actually need to check the result as we presume the existing
logic is already adequate, and sometimes programs return non-zero values
as result of valid query. I.e. this is a "safe" way to broadly protect
these scripts.
Issue: #27782
The warning for policy CMP0174 can be triggered if a project mistakenly
specifies CONFIGURE_COMMAND, BUILD_COMMAND, INSTALL_COMMAND,
or TEST_COMMAND as keywords to FetchContent_Declare() and it passes
an empty string after the keyword. It shouldn't be specifying any of those
keywords, but doing so has always worked because FetchContent_Declare()
explicitly discards them. However, when a project specifies them, they get
used internally in contexts where the policy settings are those of the
FetchContent module itself. Those settings haven't been updated past
CMake 3.29, and CMP0174 came in with CMake 3.31.
Update the policy settings for FetchContent to avoid triggering the CMP0174
warning when a project erroneously specifies the prohibited keywords.
Fixes: #27157
Add the ability to modify the environment of the various steps running
as part of an external project build. This specifically adds the ability
to set them on the configure , build , install, and test steps, as well
as exposing the `ENVIRONMENT_MODIFICATION` keyword arguments to
`ExternalProject_Add_Step`, allowing customization of the environment of
custom steps.
The values of the environment variable respect the `LIST_SEPARATOR`.
Fixes: #26963
- Do not try to guess the flags to pass to "cmake -E tar" ("z" or not) based
on the extension. It is not necessary, as the archive type is autodetected
since we switched to libarchive.
- Add new tests for .tar.zst archives, which would fail without the change.
Fixes: #25062
Add an `INSTALL_JOB_SERVER_AWARE` option to `ExternalProject_Add`.
When using an explicit `INSTALL_COMMAND`, the generated commands
won't use `$(MAKE)` thus failing to connect to the outer make's
job server. Add an option enable explicit job server integration.
This is the install step's equivalent to the build step's
`BUILD_JOB_SERVER_AWARE` option added by commit bc43398e72
(ExternalProject: Enable Make Job Server with Explicit Build Command,
2023-08-09, v3.28.0-rc1~217^2). It is useful when the external
project's installation is driven by its build system. Note that with
Makefile generators, our default install command does use `$(MAKE)` to
connect to the outer make's job server.
Issue: #26398
The can_fetch_default variable needs to be set before the call to
_ep_write_gitupdate_script(). Move it to before that call and always
set the variable, even if arg_SCRIPT_FILE is not set. This makes the
generated git update script file easier to follow if someone tries to
follow what it is doing or wants to investigate problems and run it
manually.
Fixes: #26164
In 462e583267 (ExternalProject: Switch download, update and patch to
use _EP_ vars, 2024-05-13), the svn_username and svn_password variables
were only updated appropriately in the svn download implementation, but
not in the svn update implementation. This was easily missed in part
because the old implementation was relying on behavior that differed
from the documentation for get_property(), and the new implementation
tried to keep the intermediate variables from the old implementation but
missed this subtle aspect.
Issue: #26152Fixes: #26148
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
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>
Craig Scott
Matthew Woehlke
scivision
Jérémie Dumas
Peter Kokot
Evan Wilde
Javier Martín
Brad King
Chris WrightandCraig Scott