search

cmake-basis / legacy

Legacy CMake BASIS project for versions 3.2 and older. For newer versions, go to
https://github.com/cmake-basis/BASIS
Other
13 stars 11 forks source link

Super-build of external project modules #528

Closed schuhschuh closed 8 years ago

schuhschuh commented 8 years ago

Instead of including external modules as Git submodules, it would be better when these external modules would be build using the ExternalProject.cmake module. The top-level project will only contain the/a BasisProject.cmake with the meta-data of the external project such as its dependencies on external packages and other project modules as well as the module name. The accompanying CMakeLists.txt file will instead of basis_project_impl call a new macro such as:

basis_add_external_project(GIT_REPOSITORY <url>)

The arguments such as the download options are passed on to the ExternalProject_Add command. Other arguments for ExternalProject_Add are retrieved from the BasisProject.cmake file. Most importantly, this file defines the external and internal dependencies of the module which have to be looked for during the configuration of the top-level project and the location of the found dependencies must be passed on to the configure command used by ExternalProject_Add. The information of the BasisProject.cmake file should be sufficient for simple BASIS-based project modules. Modules which have additional options and build settings may need further arguments to be passed in the CMakeLists.txt file of the external module to the ExternalProject_Add command.

This approach can in the future also be used to add non-BASIS-based projects as modules of a BASIS-based top-level project. Eventually this could be extended to build third-party dependencies as external modules with other project modules depending on these external dependencies.

Related issue of #274.

ahundt commented 8 years ago

Hopefully I read this issue correctly, but #514 may be relevant to this, perhaps we should just support that tool for super-build situations? Seems like it would restrict the scope of cmake-basis and allow some offloading of development work plus some very useful features.

schuhschuh commented 8 years ago

Hunter looks great. More relevant to the actual super-build setting. Just thinking about this one here, ExternalProject is actually not necessary for what I had in mind. All that is needed is that during the configure step, the source files of the missing modules are being downloaded. Then they can just be processed by add_subdirectory. No actual need for a super-build which makes things a lot less error prone and ensures that options/cache entries added by modules are available to the user when configuring the top-level project.

I also feel that Hunter is performing all build steps during the project configuration already? Or is it just setting package variables such as include directories and library file paths based on where they will be after the external package was built during the build step. Sounds more reasonable. But I wonder how CMake likes it when library files do not exist during the "generate" step.

ahundt commented 8 years ago

I think it may be best to ask that question on the hunter issue page, the developer seems quite responsive

schuhschuh commented 8 years ago

I've just tried the hunter-simple example project and it is as I suspected from studying the Hunter CMake code. All steps, download, configure, build, and installation are carried out by Hunter using execute_process during the CMake configure step of the project. This is quite a downside IMHO, although I understand why this is the case. Probably best is still a separate super-build of all dependencies and the project itself using either a separate CMakeLists.txt or ExternalProject_Add for all dependencies as well as the project itself.