Clean ExternalProject patch mess

[drdanz]

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

[drdanz]

Most patches are merged. The only one missing should be SOURCE_DIR_PERSISTENT

[drdanz]

CMake 3.18 was just released, and it adds a very relevant new GIT_REMOTE_UPDATE_STRATEGY option.

See:

• https://cmake.org/cmake/help/v3.18/module/ExternalProject.html
• https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4239
• https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4818

ExternalProject — CMake 3.18.0 Documentation

GitLab

ExternalProject: git on rebase failure tag and checkout (!4239) · Merge Requests · CMake / CMake

Fixes: #16528 Topic-rename: ep-git-update-strategy

GitLab

ExternalProject: Fix remote checkouts and omissions from git update strategy (!4818) · Merge Requests · CMake / CMake

The 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...

[traversaro]

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.

[drdanz]

Summarizing, the strategies are:

• CHECKOUT - Ignore the local branch and always checkout the branch specified by GIT_TAG
• REBASE - 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 strategy

We 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

[traversaro]

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 75e8943, right?

[drdanz]

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

[traversaro]

Ah, I see.

[traversaro]

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

CMake/gitclone.cmake.in at master · Kitware/CMake

Mirror of CMake upstream repository. Contribute to Kitware/CMake development by creating an account on GitHub.

[traversaro]

Anyhow, before switching to upstream ExternalProject we need:

• Finish to switch to FetchContent-based bootstram and document how to do that
• Depend on CMake 3.18 (not strictly necessary, but useful to rely on Clean ExternalProject patch mess #50 (comment))

Once this is done, the main benefit will be:

• Reduced mantainers problems from ExternalProject
• Support for Xcode in recent version of CMake (XCode 12 and CMake 3.19 support #368)
• Be able to simplify a lot the behavior of superbuild when changing tags (see bold part in https://github.com/robotology/robotology-superbuild/blob/c3be3486a51afed79a9ee4a41dd453e1fe175346/doc/change-project-tags.md). We could just switch to 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.
• Increase in speed in bootstrap

GitHub

robotology-superbuild/change-project-tags.md at c3be3486a51afed79a9ee4a41dd453e1fe175346 · robotology/robotology-superbuild

CMake/YCM-based superbuild to simplify the build process of robotology projects. - robotology-superbuild/change-project-tags.md at c3be3486a51afed79a9ee4a41dd453e1fe175346 · robotology/robotology-...

[traversaro]

• Finish to switch to FetchContent-based bootstram and document how to do that

Done in #403 .

[traversaro]

For reference, the patch at the time of last import was 582b5bc (that was imported on top of https://gitlab.kitware.com/cmake/cmake/-/commit/e67e4dbaadf3583d665fb5409b425e1a238d9748).

GitLab

CMake Nightly Date Stamp (e67e4dba) · Commits · CMake / CMake · GitLab

CMake, the cross-platform, open-source build system.