changes to how kdepimlibs and kdebase/workspace are installed and found
brad.king at kitware.com
Fri Dec 19 19:40:43 CET 2008
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.
> 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.
More information about the Kde-buildsystem