[CMake] SuperBuild whoes

[Michael Wild]

On 04/25/2011 04:51 PM, Michael Hertling wrote:
[...]
>>
>> 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?

That's true, but all the sub-projects are under my control, so I can
take care of it.

> 
>> [...] 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.

Good point. I will do something like this:

get_property(FOOBAR_INCLUDED GLOBAL PROPERTY FOOBAR_INCLUDED DEFINED)
if(NOT FOOBAR_INCLUDED)
# include FooBarLibraryDepends.cmake here
set_property(GLOBAL PROPERTY FOOBAR_INCLUDED TRUE)
endif()

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

Michael