GitLab now uses a `/-/` component between the `group/project` part of
the URL and the `{issues,merge_requests,tree}` part so that it can
support `group/subgroup/project` with arbitrary depth.
The refactoring exposed that the original implementation
was referring to an undefined variable src_name, which was
previously only used in error messages. This has been fixed
as part of the refactoring work.
Fixes: #20336
When looking at `list(FIND)` result, zero index is ignored due to
incorrect error handling, and users can't set dependencies on mkdir
step.
Fixes: #20605
In commit 5bc6230741 (ExternalProject: Option to turn off recursive
update of git submodules, 2019-10-16) we implemented the feature in the
clone script written by `_ep_write_gitclone_script` but not in the
update script written by `_ep_write_gitupdate_script`. Implement the
latter by factoring out a common helper to use in both places.
Fixes: #20335
The clone step checks out the cloned branch but is always followed by an
explicit checkout of the desired `GIT_TAG`. Tell `git clone` not to
check out.
-- When using default values for the external project forward GHS platform
variables so that the external project builds with the same tools as
the original project.
-- Fix issue with bad top level project when GHS_PRIMARY_TARGET is set but has
no value. In this case treat it as unset and use default value.
When GIT_SHALLOW is used, the '--depth 1 --no-single-branch'
arguments are add. It means that only branch names and tags
is downloaded to repository. Most Commit Hash is not working.
With this commit the documentation was updated, to describe
the limitation of GIT_SHALLOW.
Since commit 79410eeb1f (ExternalProject: Initialize Git submodules
recursively and on update (#16083), 2016-04-26, v3.6.0-rc1~105^2) our
`git submodule update` step uses the `--init` flag. This makes the
prior `git submodule init` unnecessary.
In commit b6f6cac378 (ExternalProject: add LOG_DIR option that allows
overriding of log location, 2018-10-12, v3.14.0-rc1~515^2~1) the log
directory got its own option. The intention was to fall back to the
stamp directory by default. However, the implementation actually only
falls back to the same default as the stamp directory and does not
consider a custom stamp dir.
Update the default log dir computation to fall back to whatever is the
final selection for the stamp dir.
Fixes: #19000
The output is only merged for a step if it is logging to file. This
option is ignored for steps that are logging normally.
A minor grammatical error has also been fixed as part of this change.
This option only has an effect if at least one of the other LOG_<step>
options is enabled. If an error occurs for a step which has logging to
file enabled, that step's output will be printed to the console. For
cases where a large amount of output is recorded, just the end of that
output may be printed to the console.
Most steps support the logging into a file but the patch command is a
notable exception. This commit adds the LOG_PATCH options that acts as
the other LOG_* options.
In some circumstances the user of ExternalProject may not desire the
split log files for stdout and stderr. In particular with a project has
many errors it can be difficult to correlate the output error with the
command that it resulted from.
This commit adds the LOG_MERGED_STDOUTERR option that when enabled
outputs into a unified <name>-<step>.log for each step. If disabled it
will default to the previous behaviour of <name>-<step>-out.log and
<name>-<step>-err.log.
In some situations it can be helpful to separate out the location of the
log files from the location of the stamp files. For instance if you have
a continuous integration that exposes the location where log files are
stored.
This commit adds an option that allows a user to override the default
behaviour of putting the log files in STAMP_DIR called LOG_DIR. The
previous behaviour of putting the log files into the STAMP_DIR applies
if LOG_DIR is not specified.
* The code snippets in the docs consist of CMake code mixed
with syntax definition punctuation like < > [ ] ... Therefore
a pure CMake lexer is inadequate. Here it is replaced by a
CMake syntax definition parser.
* Fixed syntax definition snippets in FindPkgConfig.cmake to
make best use of syntax highlighting. This source file is the
hardest to support because it contains comparison operators
<= = >=, which need special attention to avoid confusion
with the placeholder indicators <...>.
* Fixed syntax in execute_process.rst (there were unbalanced
brackets).
* Disabled syntax highlighting for long string examples in
cmake-language.7.rst.
* No highlighting of removed syntax in CMP0049
* To inspect the outcome of this patch, see e.g. the pages
* manual/cmake-buildsystem.7.html
* module/ExternalProject.html
* module/FindPkgConfig.html
which are particularly rich in complex code snippets.
Since in some situations, ExternalProject module may be included in
a sub-directory, functions will be available in the global scope but
local variables like "_ep_keywords_<keyword>" will not be defined, this
commit checks and reports an error indicating that the ExternalProject
module must be explicitly included before using any of the ExternalProject_*
functions that require the module's inclusion within the current scope
or above.
Co-authored-by: Pablo Hernandez <pablo.hernandez@kitware.com>
Co-authored-by: Craig Scott <craig.scott@crascit.com>
Generalize the fix in commit v3.11.0-rc4~8^2 (ExternalProject: Fix cache
generation when last args ends with "-NOTFOUND", 2018-03-10) to work for
any argument rather than just the last one.
ExternalProject can now successfully generate the cache file when any
(not only the last one) cache variable associated with either
`CMAKE_CACHE_ARGS` or `CMAKE_DEFAULT_CACHE_ARGS` configure step option
is set to a `<value>` ending with `-NOTFOUND`.
3c413e2a GENERATOR_IS_MULTI_CONFIG: Use for multi-config checks in Modules
c267ea1c GENERATOR_IS_MULTI_CONFIG: Use for multi-config checks in Tests
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1627
When the `CMAKE_GENERATOR` option is given to `ExternalProject_Add`,
look also for option `CMAKE_GENERATOR_INSTANCE` to pass on to cmake as a
cache definition. When no `CMAKE_GENERATOR` option is given explicitly
then use the current project's `CMAKE_GENERATOR_INSTANCE` (since we
already use its CMAKE_GENERATOR).
d45aa38a Add dev notes for topic 'curl_netrc_options'
60c272b6 ExternalProject: Add support for NETRC and NETRC_FILE suboption
754e39dd Add testcases for file(DOWNLOAD|UPLOAD) netrc options
5d67e902 file(DOWNLOAD|UPLOAD): Add 'NETRC' and 'NETRC_FILE' suboption
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Ruslan Baratov <ruslan_baratov@yahoo.com>
Merge-request: !1376
