changes to how kdepimlibs and kdebase/workspace are installed and found

[Brad King]

Maciej Mrozowski wrote:
>> 3.) Hack the export file to put if(EXISTS) around each import rule to
>> check that the imported file exists.  Perhaps in the future CMake could
>> generate this automatically.  I didn't consider it since the import rule
>> is put in an export file that gets installed along with the target.  In
>> your case you have a packaging mechanism that splits the install tree up
>> with more granularity than CMake knows.
> 
> Hmm, I don't understand the purpose .. to always install (somehow) those 
> exports and make them find libraries they 'represent'? Don't we have 
> FindXXX.cmake already for that purpose?

The FindXXX modules *search* for the packages.  The whole point of the 
export files is to *know* where to find libraries because they are 
installed together.  I'm proposing that the import rules say "my library 
would be here if it is installed".  Basically each import rule would 
look at its one known location to see if the library file exists before 
reporting it.

>> 4.) Keep the single export file but teach KDE4WorkspaceConfig.cmake to
>> detect by some other means (existence of a mark file that comes with
>> each package) whether each target is really available.  Then set boolean
>> variables or properties on the imported targets to indicate availability.
> 
> Yeah, but that seems to be against of the goal to introduce out-of-the-box 
> library finding/importing.
> 
> Is there any way of forcing install (TARGETS EXPORT) or install (EXPORT) 
> without dependency information

Not currently.  The dependencies must be known because otherwise there 
is no way to report them when the targets are imported.  Note that the 
link dependencies for a shared library are needed even if the link 
interface is empty (unfortunately it is needed for proper linking to the 
shared lib on some platforms).

Consider:

   add_library(foo SHARED foo.c)
   add_library(bar SHARED bar.c)
   target_link_libraries(bar foo)
   set_property(TARGET bar PROPERTY LINK_INTERFACE_LIBRARIES "")
   install(TARGETS foo bar DESTINATION lib EXPORT myexp)
   install(EXPORT myexp DESTINATION lib/myexp)

In the install tree the file

   root/lib/myexp/myexp-release.cmake

contains the code

# Import target "foo" for configuration "Release"
SET_PROPERTY(TARGET foo APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
SET_TARGET_PROPERTIES(foo PROPERTIES
   IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libfoo.so"
   IMPORTED_SONAME_RELEASE "libfoo.so"
   )

# Import target "bar" for configuration "Release"
SET_PROPERTY(TARGET bar APPEND PROPERTY IMPORTED_CONFIGURATIONS RELEASE)
SET_TARGET_PROPERTIES(bar PROPERTIES
   IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE "foo" # (*)
   IMPORTED_LOCATION_RELEASE "${_IMPORT_PREFIX}/lib/libbar.so"
   IMPORTED_SONAME_RELEASE "libbar.so"
   )

The line marked (*) needs to know both the name of the imported target 
"foo" and that it exists.  Linking to "bar" is not always possible 
without it (even though foo is not in bar's link interface some linkers 
want to find foo when linking to bar).  If foo and bar appear in 
separate exports then installed bar does not know about the installed 
foo so it complains.  This is why separating the exports would require 
support for inter-dependent exports.

What you really want is to be able to install foo and bar in separate 
packages, where bar's package depends on foo's, right?  What if the 
above import blocks were to appear in separate files so you could put 
them in the separate packages?  Each package would contain its library 
and the corresponding piece of the export file.  The file currently 
holding the above blocks could instead do an optional include to load 
the import rules for libraries that have been installed.

-Brad