Allow building the superbuild with "Shallow" cloned repos

[nunoguedelha]

When testing a given PR from a project for which we need a specific release of the superbuild, it would be quite interesting and effective to be able to populate the superbuild with shallow clones of the sub-projects. the motivation for such choice is the following:

• building the superbuild from a custom ProjectTags requires to download all the sub-projects from scratch, due to a limitation of cmake, @traversaro correct me please if I'm wrong here. At least, it's the safer way to go so far, due to that limitation.
• This implies a massive download of repos, which can be a problem for developers having slow and/or limited internet connection.

This problem would be avoided if we could just download the required commit for each repo, which can significantly reduce the amount of data to download for some repositories with a large history. We can also avoid to download all the tags, branches, etc.

This way of cloning a repository is done through a Git Shallow Clone. Actually I added a post on this in Teams some time ago (same link).

This is specially interesting for people working on multiple projects.

@traversaro @diegoferigo @S-Dafarra @gabrielenava

What do you think?

[traversaro]

This implies a massive download of repos, which can be a problem for developers having slow and/or limited internet connection.

If you need a specific version of dependencies and you are download limited, probably the best option is to just install them via conda, as via conda you can specify the required version for each dependency (see #652). At the moment we just have the latest version, but as soon as #652 is merged we will start to generate new packages every week, and this will permit us to offer all the versions of the dependencies.

building the superbuild from a custom ProjectTags requires to download all the sub-projects from scratch, due to a limitation of cmake, @traversaro correct me please if I'm wrong here.

Actually as long as you switch between tagged releases, it should work fine, the problem is switching from a branch to another (like going from Stable to Unstable and back).

When testing a given PR from a project for which we need a specific release of the superbuild, it would be quite interesting and effective to be able to populate the superbuild with shallow clones of the sub-projects.

ExternalProject offers a GIT_SHALLOW option (see https://github.com/robotology/ycm/blob/ea84ca0ad74f036c247fc7cc78c255614b15156b/cmake-next/proposed/ExternalProject.cmake), however note that it has this limitations:

If GIT_SHALLOW is enabled then GIT_TAG works only with branch names and tags. A commit hash is not allowed.
Furthermore, I guess that YCMEpHelper would need to modify to enable optional support for it, see https://github.com/robotology/ycm/blob/ea84ca0ad74f036c247fc7cc78c255614b15156b/modules/YCMEPHelper.cmake#L1048 .

So I am not sure if it make sense to add this complexity, for bandwidth limited user I think that pushing for a robust solution (that also support caching, etc etc) such as conda binaries may be the best option.

[nunoguedelha]

So I am not sure if it make sense to add this complexity, for bandwidth limited user I think that pushing for a robust solution (that also support caching, etc etc) such as conda binaries may be the best option.

Indeed, you're right, it is probably not worth adding such complexity if we have the conda binaries solution, specially considering that...

Actually as long as you switch between tagged releases, it should work fine, the problem is switching from a branch to another (like going from Stable to Unstable and back).

(I wasn't aware of this subtlety).

In addition, this limitation...

If GIT_SHALLOW is enabled then GIT_TAG works only with branch names and tags. A commit hash is not allowed.

... is really a deal-breaker.

So, unless anyone has anything to add, I'll close this issue.