schuhschuh
commented
8 years ago 
Andrew's comment:
what do you think of creating a super build template, or supporting super-build in the standard basis template?
Open schuhschuh opened 8 years ago
schuhschuh
commented
8 years ago
Andrew's comment:
what do you think of creating a super build template, or supporting super-build in the standard basis template?
schuhschuh
commented
8 years ago
;) Yes, I was thinking about it when making the final touches for the current one, but thought this will require a bit more time. What I've done previously was adding a build/CMakeLists.txt file which only implemented the super-build. The root CMakeLists.txt would yet just trigger a normal build of the project itself without the dependencies. This works actually quite nice, but users got quite confused about the difference of using either the top directory or the build/ directory as source directory for the CMake build configuration.
A possibly more intuitive / seamless integration would be to have the basis_find_package command add necessary rules for the build of an external project instead if it could not find a suitable installation. Or at least the root CMakeLists.txt would include the optional super-build. If possible to be realized, I would prefer making basis_find_package smarter. The difficulty is, however, to have a two stage build in that case, i.e., first all dependencies and the project itself which requires another run of CMake to import the <Pkg>Config.cmake settings of the dependencies build (and installed) during the first stage. Or actually worse, after the first configuration stage, you need to trigger the build of the dependencies, and only then you can enter the final configuration and build of the project. But of course you don't want to "build" the dependencies during the first CMake "configure" step...
schuhschuh
commented
8 years ago 
Yes, I also have some code I'm planning to integrate from my old CMakeMesh repository as part of issue #257
schuhschuh
commented
8 years ago
We may also want to consider a Config.cmake script in the top level of BASIS itself. If we can make that work then it would be super easy to integrate even if it isn't built and installed in advance.
schuhschuh
commented
8 years ago
Right, I think I mentioned this somewhere. Similar to a config.h.in file for C++ maybe on another subject though. How does this solve the chicken-and-egg problem regarding configuration, build, configuration, build ?
schuhschuh
commented
8 years ago
Let's see, maybe I got your idea, but using such Config.cmake for the actual project being build, not BASIS itself. Building BASIS is actually not the bigger problem I believe. As I see it with a super-build, you (download and) build external packages first and then you can configure the build of your project. As before the build of the dependencies, you are missing the <Pkg>Config.cmake files with the information required to build your project, these need to be build first by the ExternalProject.cmake module commands before you can even configure the build system of your own project. This means that a super-build script will not only have to build the dependencies as external project, but also your project itself. That way the right build order is ensured by the ExternalProject.cmake command. Then, however, you are missing the direct access to all the options and CMake variables a user can normally set when building your project. These would have to be specified by the super-build script when adding your project as external project, i.e., ExternalProject_Add. So I guess a solution would be to generate the super-build script during the configuration of your project. Alternatively, BASIS can include a generic super-build script which reads in any specific information from a Config.cmake file configured for your project. Does that make sense ?
schuhschuh
commented
8 years ago
In particular, the Config.cmake file or build-specific super-build script would cache the options and variables set by the user when configuring the build of your project similar to the CMakeCache.txt and load them when the final build configuration step is run (i.e., the second run after all dependencies are already downloaded, built and installed).
schuhschuh
commented
8 years ago
We could set up an ExternalProject.cmake so that it forwards the internal options along.
schuhschuh
commented
8 years ago
So if basis_find_package takes care of adding external projects for the dependencies, then it probably would have to set a flag which tells the calling macro basis_project_impl that it should actually skip adding any targets but instead just add another external project target for the project itself and pass on any variables currently in the CMake cache. I think that would work quite nice.
Remains only the one question of how to deal with the download and build of BASIS itself which is required to enter this whole process in the first place. Without it you cannot even get to the point where all the project options are added to the CMake cache.
schuhschuh
commented
8 years ago See cmake-basis/legacy#274 for missuing comments lost during import.
The README describes superbuild functionality that is currently not present, so I am moving it to this issue.
Future Work
Once the CMake BASIS package is installed, can be used to build other BASIS projects. Alternatively, if the package is not found, each BASIS project which is built on top of BASIS and implements the super-build feature, retrieves and builds a local copy using CMake's [ExternalProject.cmake][9] module This super-build methodology, which is becoming popular in the CMake community could be utilized by BASIS to not only ease the development and maintenance of separately managed software projects, but also enable the fusion of these more or less independently developed software packages into so-called superprojects. In this context, the separately managed software packages are considered components of the superproject. TODO: The super-build methodology is not yet implemented as part of BASIS!
Besides the super-build of BASIS projects, BASIS helps create a tighter coupling between software components. The top-level project (i.e., the superproject) could contain other BASIS projects as modules, and these modules define the dependencies to other modules of the project. When the superproject is configured, a subset of these modules can be selected and only these will be build and installed. This type of modularization closely follows the [modularization approach of the ITK 4 project][10].