Clean ExternalProject patch mess

drdanz commented 10 years ago

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 commented 9 years ago

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

drdanz commented 4 years ago

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

See:

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

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?

drdanz commented 3 years ago

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 commented 3 years ago

Ah, I see.

traversaro commented 2 years ago

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 commented 2 years ago

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 https://github.com/robotology/ycm/issues/50#issuecomment-659540091)

Once this is done, the main benefit will be:

Reduced mantainers problems from ExternalProject
Support for Xcode in recent version of CMake (https://github.com/robotology/ycm/issues/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 commented 1 month ago

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

Done in https://github.com/robotology/ycm-cmake-modules/pull/403 .

traversaro commented 3 weeks ago

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 Nightly Date Stamp (e67e4dba) · Commits · CMake / CMake · GitLab
CMake, the cross-platform, open-source build system.

robotology / ycm-cmake-modules

Clean ExternalProject patch mess #50