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 _______________________________________________ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem