[cmake-developers] Multiple dependent install(EXPORT) sets

[Stephen Kelly]

Alexander Neundorf wrote:

> On Tuesday 22 November 2011, Brad King wrote:
>> On 11/22/2011 10:03 AM, Stephen Kelly wrote:
>> > Brad King wrote:
>> >> We will have to require that the install(EXPORT)
>> >> commands be invoked in dependency order (ex. A before B).  That way
>> >> when the command installing ExportB is writing library B's dependency
>> >> on A, it can transform the name using the options that had been given
>> >> to the install command for ExportA, such as its NAMESPACE.
>> 
>> This is required because ExportB will create an imported target for
>> library B and that imported target will list its dependency on an
>> imported target
>> for library A.  What is that imported target called?  Where is it
>> defined?
>>  Only ExportA knows, and then only after its install(EXPORT) has been
>> called.
> 
> Yes.
> 
> Where/why is it actually necessary to split libraries installed from one
> package into multiple Config.cmake files ?
> This is now to install separate libraries from a big kdelibs, right ?
> Maybe we (KDE) simply shouldn't do this, and just start with it once the
> big modules are broken into separate parts.

Maybe. Should nobody install multiple 'modular pieces' from one top level 
CMakeLists.txt? It's sort of superbuild without superbuild, but with the 
advantage that the sources are in the source directory.

> Then each of the smaller parts can install a Config.cmake file for all its
> libraries. If e.g. libkgui depends on libkcore, currently those two
> targets would exist in one project, but installed as two export sets.
> Once they are separated into two projects, then libkgui depends already on
> the imported target KDE::kcore (or how it is named), and referencing this
> in its Targets.cmake file works fine.

Does a target know its imported target name or is it really just the export 
mechanism? Would it be possible for the export mechanism to inform the 
targets of their imported target name and location so that that information 
can be retrieved by dependents?

Consider this:

add_library(bar)
add_library(foo)
target_link_libraries(foo bar)

install(TARGETS bar EXPORT barTargets ...)
install(TARGETS foo EXPORT fooTargets ...)

install(EXPORTS barTargets NAMESPACE myNS) # sets a property on bar that its 
                                           # imported name is myNS::bar
install(EXPORTS fooTargets NAMESPACE otherNS) # Maps from the LINK_LIBRARIES 
                                              # information 'bar' to 
                                              # 'myNS::bar' to populate the 
                                              # dependency information

This also removes the need for explicit dependencies between 
install(EXPORTS) invocations, which is already implicitly specified by the 
(public) link interface of targets build in the same build system.

> We do this already with Qt4.

You mean in FindQt4.cmake? I'm not sure it's the same situation.

>  
>> >> Furthermore, the targets file
>> >> generated for ExportB will need to include() the file generated for
>> >> ExportA using the DESTINATION given to the latter to make its targets
>> >> available.
>> > 
>> > And its FILE presumably, but why? This ties in to the question of
>> > whether
>> 
>> > find_package(B) should find the dependencies of B:
>> We could leave this part out and leave it up to the Config.cmake file
>> author to ensure ExportA's targets file is loaded when ExportB's targets
>> file is loaded.
> 

Why the Config file author? Why not the consumer of the config files? You 
mean that the author of BConfig.cmake should ensure that ExportA's targets 
file is loaded? How would it do that without a find_package(A)?

Thanks,

Steve.