Add 'rules' to install from superbuild #466
Conversation
Update Artichoke to commontk/Artichoke@b0cf6fc85d5a. Use new ExternalProject_Install_CMake to install external projects when doing a superbuild build of slicer, so that there is a functional install target for the same. This change is made synchronously with the merge of commontk/CTK#466 which no longer installs QtTesting to the build tree, and instead installs it as part of the install target for CTK; thus, SlicerBlockInstallQtTesting.cmake is (and indeed, must be, as there is no longer an install path being exported) removed. At least on Fedora, this is sufficient to produce a Slicer that can be successfully run after building the 'install' target.
Update Artichoke to commontk/Artichoke@b0cf6fc85d5a. Use new ExternalProject_Install_CMake to install external projects when doing a superbuild build of slicer, so that there is a functional install target for the same. This change is made synchronously with the merge of commontk/CTK#466 which no longer installs QtTesting to the build tree, and instead installs it as part of the install target for CTK; thus, SlicerBlockInstallQtTesting.cmake is (and indeed, must be, as there is no longer an install path being exported) removed. At least on Fedora, this is sufficient to produce a Slicer that can be successfully run after building the 'install' target.
Import ExternalProject_Install_CMake from commontk/Artichoke@b0cf6fc85d5a, and use to install (some) external projects when building the install target of a CTK superbuild. Note that this (currently) does not install DCMTK, KWStyle or QtTesting or PythonQt. KWStyle is probably not needed, but the other three should be fixed (and also, the non-installed CTK build should use their build trees rather than doing local installs). As a result, this is *NOT* sufficient yet to produce a usable install of CTK from the superbuild.
…-update * superbuild-install-rules: Add 'rules' to install from superbuild Conflicts: CMake/ctkBlockCheckDependencies.cmake
|
I was looking into doing a "super-build install" of CTK as well and was wondering what is status of this pull request? I would be willing to have a look and merge it if there are no reasons not to, even if it doesn't support all options / external projects yet. I would also work on issue #406 in parallel. |
|
@saschazelzer This effort hasn't been completed because instead the support of component installation within CMake itself should be updated. More details here: http://public.kitware.com/Bug/view.php?id=14955 Since updating CMake itself may require more work, it may be worth continuing with this topic ... I guess sending an email on the CMake developer list could be useful. |
|
Thanks for the clarification! I will send a mail to the cmake list about this topic. Anyway, the changes look small enough to warrant their inclusion in my opinion. It will take some time until CMake supports this natively and more time until we can require a recent CMake version in CTK. I suggest that I extract only the build system modifications for "super-build install support" from this merge request and bring it in a usable state (together with fixes for issue #406). |
|
Closing. This pull request is obsolete. |
Import ExternalProject_Install_CMake from commontk/Artichoke@b0cf6fc85d5a, and use to install (some) external projects when building the install target of a CTK superbuild.
Note that this (currently) does not install DCMTK, KWStyle or QtTesting or PythonQt. KWStyle is probably not needed, but the other three should be fixed (and also, the non-installed CTK build should use their build trees rather than doing local installs). As a result, this is NOT sufficient yet to produce a usable install of CTK from the superbuild.