Fwd: Kde 4.2 beta1 feedback: Notes on cmake scripts
Forwarding to the buildsystem folks: - Firstly I'd like to say thank you for an awesome kde 4.2 beta 1, it's looking really good. I would like to raise a few issues about the build scripts and offer some suggestions. I regret that I have not been able to try the latest beta 2 that was released today, but I will try it as soon as I have time. I am using GoboLinux. GoboLinux does not use the FHS, which means certain assumptions that are true for many distributions do not hold in this case. While installing KDE-4.2 beta 1 I ran in to 2 areas of trouble which required three patches in total. The first trouble spot is with the cmake modules that kde-libs installs on the system. The kdelibs-4.1.80/cmake/modules/FindKdepimLibs.cmake file specifies KDE4_LIB_DIR as the location for the kdepimlibs libraries. This does not work on GoboLinux because we do not install the whole of KDE to the same prefix instead we have /Programs/KDE-Libs/Current, /Programs/KDE-PIM-Libs/ Current, /Programs/KDE-Base/Current, etc. This means that in the Gobolinux case KDE4_LIB_DIR will point to /Programs/KDE-Libs/Current, which is obviously the wrong prefix for PIM-Libs. I solved this by substituting CMAKE_LIBRARY_PATH in the place of KDE4_LIB_DIR and setting CMAKE_LIBRARY_PATH=/System/Links/Libraries where all libraries can be found. I had a quick browse of kde web svn before sending this email and it would appear that FindKdepimLibs has changed quite a bit. I haven't had a chance to read very deeply into the code, but I hope that CMAKE_LIBRARY_PATH is used more instead of KDE4_LIB_DIR. The other problem I had was with KDE-Base-Workspace and KDE-Base- Runtime locating DBUS interface definitions in the scripts powerdevil/daemon/ CMakeLists.txt and kwalletd/CMakeLists.txt. Both scripts originially used the variable DBUS_INTERFACES_INSTALL_DIR to refer to preexisting interface definition files. On a system where all DBUS interfaces are installed in the same location this is not a problem. However, on GoboLinux each package installs its DBUS interface definitions under the package prefix and these are symlinked to /System/Links/Shared/dbus-1/interfaces/ . In the end this means when building either KDE-Base Workspace or Runtime the build script looks under the installation prefix and of course it won't find anything there because that prefix hasn't been created yet (and the files its looking for are never going to be there anyway)! To resolve this I substituted DBUS_INTERFACES_INSTALL_DIR with KDE4_DBUS_INTERFACES_DIR and set KDE4_DBUS_INTERFACES_DIR appropriately (i.e. to /System/Links/ Shared/dbus-1/interfaces) when compiling KDE-Libs. From browsing kde web svn, this seems to be the approach you are taking now. I would like to strongly encourage you to include this in the final release! :-) I include my patches with this email for clarity. I apologise for accidentally changing a WIN32 setting in 01-kwalletd-CMakeLists.patch this was not my intension and I do not know if it is appropriate or not. The patch is really just to illustrate the change I would make and by the looks of the svn code I don't think you will be needing it! Do people on this list think it is likely that these amendments might make the final release? (Not my patches, just the general ideas!) Thanks, Frank Wilson 01-powerdevil-daemon-CMakeLists.patch Description: Binary data 01-kwalletd-CMakeLists.patch Description: Binary data 01-FindKdepimLibs.patch Description: Binary data ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
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.
I like the idea and I could create complete patch for kdebase-workspace, but I
need some hints (for one workspace library and maybe example entry in
KDE4WorkspaceConfig.cmake.in) as I'm not really CMake hacker.
So far I tried to realize first step - install multiple EXPORTS - one per
library - and I run in some problem with libraries that depend on other
workspace libraries.
For example, replacing:
install(TARGETS nepomukqueryclient EXPORT kdeworkspaceLibraryTargets
${INSTALL_TARGETS_DEFAULT_ARGS})
with something like:
install(TARGETS nepomukqueryclient EXPORT nepomukqueryclient
${INSTALL_TARGETS_DEFAULT_ARGS})
install (EXPORT nepomukqueryclient DESTINATION ${LIB_INSTALL_DIR}/cmake)
(in my version I got it to be installed in /usr/lib/cmake/ - similar to pkg-
config, and added lib prefix for those cmake modules to distinguish them from
their corresponding clients)
results with:
CMake Error: INSTALL(EXPORT libnepomukqueryclient ...) includes target
nepomukqueryclient which requires target nepomukquerythat is not in the
export set.
How to handle such cases properly?
Imho it may not be possible to separately export everything as it seems that
libraries depending on each other would need to be exported together (and thus
built together, as install (TARGETS) command is responsible for it, right?).
While it should not be a problem really it would be rather workaround and it
should be done proper way of at all imho.
(as it appeared that hacking build system to not use this way of finding
packages is not that hard)
(and btw, KDE4 CMake files would really need some love in terms of
reformatting :)
--
regards
MM
--
Wyslij internetowa kartke z zyczeniami!
Kliknij http://link.interia.pl/f1ff2
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
On Friday 19 of December 2008 18:11:35 Maciej Mrozowski wrote:
install(TARGETS nepomukqueryclient EXPORT nepomukqueryclient
${INSTALL_TARGETS_DEFAULT_ARGS})
install (EXPORT nepomukqueryclient DESTINATION ${LIB_INSTALL_DIR}/cmake)
should be of course:
install(TARGETS nepomukqueryclient EXPORT libnepomukqueryclient
${INSTALL_TARGETS_DEFAULT_ARGS})
install (EXPORT libnepomukqueryclient DESTINATION ${LIB_INSTALL_DIR}/cmake)
--
regards
MM
--
Wyslij wirtualna kartke swiateczna!
Klikinij http://link.interia.pl/f1ff1
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Fwd: Kde 4.2 beta1 feedback: Notes on cmake scripts
On Friday 19 December 2008, Allen Winter wrote: Forwarding to the buildsystem folks: --- -- Firstly I'd like to say thank you for an awesome kde 4.2 beta 1, it's looking really good. I would like to raise a few issues about the build scripts and offer some suggestions. I regret that I have not been able to try the latest beta 2 that was released today, but I will try it as soon as I have time. Thanks for the feedback, but I think I have fixed all these issues just two weeks ago, i.e. after beta1, they should be in beta2. I'm building KDE currently with the stuff installed to /opt/kdesupport, /opt/kdelibs, /opt/kdepimlibs and /opt/kde4 (for all the rest), so that I think I have stumbled about all the same problems and fixed them. Please let us know if you still have problems with current svn trunk. Thanks Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
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 nepomukquerythat 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
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
On Friday 19 of December 2008 19:40:43 Brad King wrote:
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.
Actually I wouldn't really propose inter-dependent exports. It's not necessary
as KDE guys don't need it as they usually build whole workspace, and in Gentoo
we already handle inter-dependencies at package level (and we use workspace-
toplevel CMakeLists.txt so all required libraries are being found, we just
comment out not necessary add_subdirectory from build). I believe other
packagers do it similar way.
That being said, if anything - we would really only need a way to export those
workspace libraries just as they are - without dependency information (so far
attached error message occurs).
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.
Write by hand and post-process means probably some amount of serious
work/rework - not acceptable here :)
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?
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 or make it possible to manually add
dependencies (those that are going to appear in
IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE in example)?
If this considered workaround, then you can easily skip the idea as we can
workaround this problem with simple
sed -i -e 's/${KDE4WORKSPACE_KSCREENSAVER_LIBRARY}/kscreensaver/'
CMakeLists.txt
I just wanted to throw some proposition to be considered in a future. and I
would personally prefer robust solutions rather than workarounds/hacks in KDE4
or in any CMake-controlled build systems.
--
regards
MM
--
Wyslij internetowa kartke z zyczeniami!
Kliknij http://link.interia.pl/f1ff2
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
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
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
