[CMake] SuperBuild whoes

[Michael Hertling]

On 04/21/2011 03:44 PM, Michael Wild wrote:
> On 04/21/2011 02:45 PM, David Cole wrote:
>> On Thu, Apr 21, 2011 at 4:30 AM, Michael Wild <themiwi at gmail.com
>> <mailto:themiwi at gmail.com>> wrote:
>>
>>     On 04/21/2011 06:48 AM, Michael Wild wrote:
>>     > Hi all
>>     >
>>     > I'm trying to set up a SuperBuild here. Everything works nicely the
>>     > first time round I build the project. The only real problem I have is
>>     > that if I change the sources of one of the sub-projects, the
>>     SuperBuild
>>     > still thinks everything is up to date. Of course, this is fully
>>     > explainable by the fact that the SuperBuild knows nothing about the
>>     > internal dependencies of the sub-project, and since the stamp
>>     files are
>>     > all there and unchanged, it thinks everything is fine. How do I get
>>     > around this? Anybody got an idea?
>>     >
>>     > Thanks
>>     >
>>     > Michael
>>
>>
>>     Found it myself. For completeness and documentation purposes: Add a
>>     custom target which removes the *-complete (see ExternalProject.cmake on
>>     where it is located, it is a bit tricky) and -*configure stamps. Of
>>     course, it should always run and depend on the external project target.
>>
>>     The thing I'm struggling with now is installing the various sub-projects
>>     into the system. Seems like it is impossible to install an imported
>>     target [1], but guessing and hard coding the paths is also not very
>>     attractive, but probably the only way to go at the moment. If anybody
>>     has a better idea, please speak up...
>>
>>     Michael
>>
>>     [1] http://www.mail-archive.com/cmake@cmake.org/msg18336.html
>>     _______________________________________________
>>     Powered by www.kitware.com <http://www.kitware.com>
>>
>>     Visit other Kitware open-source projects at
>>     http://www.kitware.com/opensource/opensource.html
>>
>>     Please keep messages on-topic and check the CMake FAQ at:
>>     http://www.cmake.org/Wiki/CMake_FAQ
>>
>>     Follow this link to subscribe/unsubscribe:
>>     http://www.cmake.org/mailman/listinfo/cmake
>>
>>
>>
>> If your intent is *always* to run the configure and later steps of an
>> ExternalProject build, you can consider adding an extra custom step that
>> configure depends on, which does nothing, but ALWAYS runs... No need to
>> do any fancy scrounging of stamp files for this to work.
>>
>>
>> Something like:
>>
>> ExternalProject_Add(Proj1
>>   ...
>> )
>>
>> ExternalProject_Add_Step(Proj1 forceconfigure
>>   COMMAND ${CMAKE_COMMAND} -E echo "This custom external project step
>> forces the configure and later steps to run whenever a top level build
>> is done..."
>>   DEPENDEES download
>>   DEPENDERS configure
>>   ALWAYS 1
>>   )
>>
>>
>> By the way, this is how repository-based checkouts always build. A cvs,
>> git or svn checkout's update step *always* runs (by default, unless you
>> override UPDATE_COMMAND), and since the configure step depends on the
>> update step, they also always configure, build and install.
>>
>>
>> HTH,
>> David
>>
> 
> 
> Mhm, I thought I already tried this, but will check again. Thanks for
> the input.
> 
> I also solved my installation problem. By having all sub-projects
> install into a common prefix, and thanks to the wonders of RPATH and
> install_name which can handle relative paths and thanks to the fact that
> install(EXPORT) generated files are also relocatable, I can simply do a
> install(DIRECTORY) in the super project ;-) [...]

Does this mean you've the subprojects configured for installation with
a prefix of, say, ${CMAKE_BINARY_DIR}/externals and the superproject's
CMAKE_BINARY_DIR, and add

INSTALL(DIRECTORY ${CMAKE_BINARY_DIR}/externals
        DESTINATION ${CMAKE_INSTALL_PREFIX})

to the superproject's top-level CMakeLists.txt in order to relocate
the subprojects to the actual installation directory in the end?

If so, how do you cope with subprojects which incorporate paths
derived from their installation prefix as hard-coded defaults, e.g.
<prefix>/etc - or /etc if <prefix> equals /usr - for the package's
configurational data? Following your approach, if I'm not mistaken,
the subprojects would end up with ${CMAKE_BINARY_DIR}/externals/etc
and CMAKE_BINARY_DIR pointing to the superproject's build tree. Of
course, this might result in certain failures, or do I completely
misunderstand your afore-noted outline?

> [...] The only thing that required
> some thinking was writing a relocatable XXXConfig.cmake file. I think I
> will update my tutorial on the WIKI to use a un-configured, relocatable
> XXXConfig.cmake file.

Just a hint for that tutorial, though off-topic: Targets may usually
not be defined multiple times, i.e. the export file generated by
INSTALL(EXPORT ...) may not be included more than once, so the

include("@FOOBAR_CMAKE_DIR@/FooBarLibraryDepends.cmake")

should possibly be guarded by IF(NOT TARGET ...)/ENDIF() constructs.
Otherwise, the resulting FooBarConfig.cmake file must not be loaded
twice or more - unless one is aware of the imported targets' feature
of being, say, "half-scoped", cf. [1]. This might be an uncomfortable
limitation, in particular w.r.t. multi-component packages. Regrettably,
such IF(NOT TARGET ...)/ENDIF() constructs can hardly be automated, so
one could perhaps consider to allow redefinitions for imported targets.
Due to the absence of sources, this should be much easier to implement
than for non-imported targets.

Regards,

Michael

[1] http://www.mail-archive.com/cmake@cmake.org/msg29441.html