| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
Fixes: #21624
|
| |
|
| |
Fixes: #21208
|
| |
|
| |
Fixes: #21123
|
| |
|
|
| |
Fixes: #20579
|
| |
|
| |
Fixes: #19875
|
| |
|
| |
Fixes: #20526
|
| |
|
| |
Relates: #18754
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A main scenario where this is needed is when a git operation
needs the password to a private key and asks for it on the
console. Without this change, such operations can appear to
hang indefinitely with no prompt if QUIET is in effect (which it
is by default).
Another scenario this addresses is when progress of a
download or update should be shown. Without this change,
all such progress is buffered with some generators and will
only be shown at the end, which defeats the purpose of logging
any progress to begin with.
Relates: #18238
|
| |
|
