Closed schuhschuh closed 8 years ago
We also may want to take advantage of #514 for this
I don't think we need anything fancy such as Hunter here. All this is about is that a project can declare that certain directories, if they exist, contain a module. Whether it is via git submodule or a manual extraction/copy of additional source files into the directory doesn't matter. Better would of course #528. Which then comes down to a project not to use Git submodules directly, but via a BASIS download functionality similar to Hunter's download function, but without any configure and build step.
Here's the reason for this in the implementation:
Instead of a boolean MODULE option, BASIS will add a cache entry MODULE with value "NOTFOUND" to indicate that the external module is missing for some reason.
BASIS could of course also try to run git submodule update --init -- <missing_module_dir>
, but I am not sure if that is a good idea. Eventually this "feature" is no longer necessary once #528 is implemented. I just needed something quick for now.
When the source tree of a project module is included as Git submodule, it is an "external module". As long as the Git submodule is not initialised and update, the respective subdirectory is empty and does not contain a BasisProject.cmake file. A top-level project should still be able to explicitly declare these external Git submodules such that
basis_project_modules
has a complete list of available modules. Instead of aMODULE_<MODULE>
option, aNOTFOUND
entry should be added to the cache if the module source files are missing. When the module is requested either as dependency of another module or by the user (e.g., on the command-line), an error message should make aware that the module source files are missing possible due to a forgottengit submodule update --init -- <module_dir>
call.