Open schuhschuh opened 8 years ago
Comment by schuhschuh
Thursday Jan 16, 2014 at 18:21 GMT
Andrew's comment:
what do you think of creating a super build template, or supporting super-build in the standard basis template?
Comment by schuhschuh
Thursday Jan 16, 2014 at 18:21 GMT
;) 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...
Comment by ahundt
Thursday Jan 16, 2014 at 18:24 GMT
Yes, I also have some code I'm planning to integrate from my old CMakeMesh repository as part of issue #257
Comment by ahundt
Thursday Jan 16, 2014 at 18:28 GMT
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.
Comment by schuhschuh
Thursday Jan 16, 2014 at 18:30 GMT
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 ?
Comment by schuhschuh
Thursday Jan 16, 2014 at 18:42 GMT
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 ?
Comment by schuhschuh
Thursday Jan 16, 2014 at 18:45 GMT
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).
Comment by ahundt
Thursday Jan 16, 2014 at 18:46 GMT
We could set up an ExternalProject.cmake so that it forwards the internal options along.
Comment by schuhschuh
Thursday Jan 16, 2014 at 18:54 GMT
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.
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].