Using CPM.cmake to retrieve CMake modules

[itavero]

We have several CMake scripts/modules that we want to reuse across projects.
In the past we put them in a separate Git repository, added that repository as a submodule in our project repository and then manually added the path to the submodule to CMAKE_MODULE_PATH in the CMakeLists.txt of that project.

Now that we plan to use CPM.cmake for retrieving other CMake projects, we are wondering if this could also be used to fetch the modules.
Initially I tried adding a CMakeLists.txt to the repository that contains the modules, something like:

# This repository does not provide any targets out of the box, only CMake modules.
# Therefor, this file only adds the current directory to the CMAKE_MODULE_PATH.
list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR})
# PS: Also tried a set command with PARENT_SCOPE enabled, but this yielded the same results.

And adding the repository in the project using something like:

CPMAddPackage(
  NAME module-repo
  GIT_REPOSITORY git@gitlab.com:group/path/to/module-repo.git
  GIT_TAG master
  EXCLUDE_FROM_ALL YES
)

But unfortunately this does not seem to update the CMAKE_MODULE_PATH (checked with a message statement), so if I later on try to include() any of the modules from that repository it fails.

Would it be possible to manage this through CPM as well (as I'd rather only have as single way of pulling in external code, which this of course still is)?
And what way would you suggest to go about this?

Update: Looking a bit further into the examples, it seems that the repositories mentioned in the CMake script snippets, simply declare all the functions in the CMakeLists.txt rather than having a separate .cmake module file. I guess that approach could also work, but then the existing repositories would need changes that would either make them incompatible with older projects (that still use the submodules), or we would have to include the available modules all in the CMakeLists.txt of that repository. 🤔

[TheLartians]

As you've discovered in the snippets, I prefer separate small repositories for CMake projects (e.g. as I did here, here or here), which IMO simplifies maintenance and allows users to cherry-pick only the functionality that they need.

However in your approach I think that the issue might be that the updated CMAKE_MODULE_PATH goes out of scope after the CMakeLists.txt is finished processing, so the parent project is left with the unchanged scope. One way to solve this would be to define an initialisation function (or macro) hat updates the module path in the scope where it is called.

[itavero]

In the end we added a CMakeLists.txt to all of these repositories that would simply add the "local" directory with the CMake modules (e.g. within the same repository) to the module path and also include all the modules provided by that repository, so they would be available where the package is added.

[flagarde]

@itavero I had the same problem. This is what I did https://github.com/flagarde/CMakeMM . I took the idea from other repo but rewrite it because it was missing some features I wanted

Original Idea : https://github.com/vector-of-bool/CMakeCM.

Basically I splitted the tool and the Modules.

I have then 2 repos :
https://github.com/flagarde/CMakeMM (tool)
https://github.com/flagarde/CMakeCM (my personal modules)

Then i twist the problem I first download CMakeMM and then CMakeMM download the CPM.Module which download CPM

[ClausKlein]

@itavero You may have a look at https://github.com/aminya/project_options#usage

I use fetch it with CPM.cmake in many of my projects

CPMAddPackage("gh:aminya/project_options@0.26.3")