Closed drdanz closed 3 weeks ago
Most patches are merged. The only one missing should be SOURCE_DIR_PERSISTENT
CMake 3.18 was just released, and it adds a very relevant new GIT_REMOTE_UPDATE_STRATEGY
option.
See:
GitLabFixes: #16528 Topic-rename: ep-git-update-strategy
GitLabThe initial implementation of the git update strategy in !4239 had a number of problems: * When using the `CHECKOUT` strategy, the local ref was mistakenly checked out instead of...
CMake 3.18 was just released, and it adds a very relevant new
GIT_REMOTE_UPDATE_STRATEGY
option.
If that permits to easily switch between different branches back and forth the history of the repo, that would be extremly useful.
Summarizing, the strategies are:
CHECKOUT
- Ignore the local branch and always checkout the branch specified by GIT_TAGREBASE
- Current strategy.REBASE_CHECKOUT
- Same as REBASE except if the rebase fails, an annotated tag will be created at the original HEAD position from before the rebase and then checkout GIT_TAG just like the CHECKOUT strategyWe could keep the strategy in a variable and somehow change it to a different one depending on DEVELOPER_MODE, and/or have some command to change it when you want to switch branch...
Also, if we want to think a different strategy, it could be possible to add it.
Anyway, I don't know if the part of code that was just removing the git repository and cloning it again was removed in this change, we should check that... If it was removed, I think that we can just switch to the ExternalProject
upstream
Anyway, I don't know if the part of code that was just removing the git repository and cloning it again was removed in this change, we should check that...
In any case I guess the related modification was removed in https://github.com/robotology/ycm/commit/75e8943c7d45d35075d7300dd1a6967fc92fff0b, right?
In any case I guess the related modification was removed in 75e8943, right?
That commit removed only the property to enable/disable the new behaviour, not the actual change of behaviour
Ah, I see.
Anyway, I don't know if the part of code that was just removing the git repository and cloning it again was removed in this change, we should check that... If it was removed, I think that we can just switch to the
ExternalProject
upstream
The code is still there: https://github.com/Kitware/CMake/blob/a7b325e203a45f3c8d4a64fd3338079e0a14e250/Modules/ExternalProject/gitclone.cmake.in#L15 . However, the vendored ExternalProject is taking a lot of energy, so personally I think that we should document this change and eventually go with the upstream ExternalProject. Out of all the users of ycm-based superbuild that I am aware of, nobody uses the update with repos with which they are working. Instead, either they set the devel mode for their repo to ensure that it is not update, or directly they never call the superbuild update. Out of the users I interacted with, I never met a user that was able to understand what the superbuild was doing when updating a repo with local changes, so no one ever did that to avoid confusion.
GitHub
Mirror of CMake upstream repository. Contribute to Kitware/CMake development by creating an account on GitHub.
Anyhow, before switching to upstream ExternalProject we need:
Once this is done, the main benefit will be:
CHECKOUT
and do not explain to users that they need to re-download the superbuild if they want to change the tag of their repo.GitHub
CMake/YCM-based superbuild to simplify the build process of robotology projects. - robotology-superbuild/change-project-tags.md at c3be3486a51afed79a9ee4a41dd453e1fe175346 · robotology/robotology-...
- Finish to switch to FetchContent-based bootstram and document how to do that
Done in https://github.com/robotology/ycm-cmake-modules/pull/403 .
For reference, the patch at the time of last import was https://github.com/robotology/ycm-cmake-modules/commit/582b5bca17c31ab511d6cba7b9a8111fc91e0e55 (that was imported on top of https://gitlab.kitware.com/cmake/cmake/-/commit/e67e4dbaadf3583d665fb5409b425e1a238d9748).
GitLab
CMake, the cross-platform, open-source build system.
ExternalProject is a mess due to the number of patches and patches for the patches applied. It would be nice if the patches were available as .diff in order to see what was actually applied, and to make it easier to port them to CMake, and to update from CMake