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

[Brad King]

Maciej Mrozowski wrote:
> On Thursday 18 of December 2008 20:31:42 Brad King wrote:
> 
>> Perhaps we can split it into
>> multiple INSTALL(EXPORT) files.  Then use a customized
>> KDE4WorkspaceConfig.cmake file that loads multiple export files.  The
>> config file can check for each export file and provide it if it is
>> available.  Some boolean variables can be set to indicate what was found.
[snip]
> results with:
> CMake Error: INSTALL(EXPORT "libnepomukqueryclient" ...) includes target 
> "nepomukqueryclient" which requires target "nepomukquery"that is not in the 
> export set.
> 
> How to handle such cases properly?

Oops, in my proposal I didn't realize the libraries were interdependent. 
    For some reason I was thinking they were all separate modules 
sharing a namespace.  Currently there is no way to do this unless the 
builds are separated too (where each library exports itself for import 
by its dependents).  The design of the automatic export file generation 
and installation was greatly simplified by enforcing the dependencies 
instead of having some mechanism for interdependent exports.  I 
currently have no plans to support inter-dependent exports but it could 
be done in the future.

Here are some other ideas:

1.) Write the export files by hand since they are for packages that 
always install to a specific location and always provide the same thing. 
  This is not very maintainable though.

2.) Post-process the export file to divide up the import rules.  I 
cannot guarantee the exact layout of these files will remain the same in 
future CMake versions though.

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.

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.

Note that the import files are split into two parts.  One part creates 
the imported targets and then loads the other part.  The other part 
actually imports targets under a given configuration.  #3 would be 
applied to the latter part.  #4 can work because the former part always 
creates all the targets.

-Brad