Making CMake/common usable as a .gitmodule in subprojects

[rdumusc]

The new CLONE_SUBPROJECTS option offers extra granularity between building with subprojects and clone operations. This is what we discussed today but I am not sure if such fine-grained control is needed. We could also simply replace DISABLE_SUBPROJECTS with a single SUBPROJECTS=ON switch. Both solutions would satisfy the criteria of no clone operations during the configure step by default.

[tribal-tec]

Looks good. Missing Changelog though. For integration into the projects wrt submodule instead of gitexternals, you would like to that for the release already?

[eile]

Is there a use case where using subprojects and cloning sub projects needs to be separated? I would have one option for both, SUBPROJECTS=ON as you suggested.

[rdumusc]

Right, doing the changelog now.
Yes, we could do it for the release while we are touching all projects, if everybody agrees.
Yes, now that I've thought about it again I believe this is the best approach. Having subprojects ON is a reasonable default, because if you have (one or more) subproject sources you most likely want to use them. What is important is that users have the flexibility to get the subprojects the way they want (manual git clone, automatic clone missing projects with -DCLONE_SUBPROEJCTS=ON, scp to a remote machine, pointing to an existing COMMON_SOURCE_DIR, etc...), without side-effect on the sources during the configure phase by default, which is the major complaint we received. Having a single SUBPROJECTS=ON switch does not give the same flexibility.

[tribal-tec]

As a matter of fact, the only recommended way I would document is the new submodule one. I was considering after we have updated all our projects, we can remove GitExternal.cmake and move what we still need for subproject cloning to SubProject.cmake. If we don't reach a conclusion now, we could discuss this in the next team-meeting.

[rdumusc]

good to merge?

[tribal-tec]

+1 from my side

[hernando]

This looks suspicious to me. If you do this and I need to update the CMake/common submodule in my working copy do I need to git submodule init again?

[rdumusc]

This deinit only applies to subprojects. In for some reason you want to have a clone of CMake/common in a subproject, then yes, you need to init it there. That seems logical to me, do you have a use case in mind where this isn't what you expect?

[hernando]

Not that it deserves attention. I thought it was applying also to the top level CMake/common

[rdumusc]

no, because the top-level one is cloned directly as a git submodule with clone --recursive, it no longer goes through git externals.