Re: changes to how kdepimlibs and kdebase/workspace are installed and found
On Thursday 18 December 2008, Alexander Neundorf wrote: Hi, On Thursday 18 December 2008, Maciej Mrozowski wrote: On Tuesday 09 of December 2008 01:42:14 Alexander Neundorf wrote: [...] Hi I have some questions related to mentioned changes in KDE4 build system. Introducing these methods will surely make it possible to keep CMake modules easier to maintain in the future as it should even effectively eliminate the need of FindXXX.cmake files for cmake-controlled libraries. And while this change is very good in general and I'm all for it - explicitly merging all workspace libraries in one logical unit (KDE4Workspace) effectively killed our automatic package building facility in Gentoo - the one that relies on splitting packages at library/application level. (so far it affects only some additional kdeartwork/kdetoys modules, but it's supposed to eventually spread everywhere I guess). The problem is - all workspace library targets (those with EXPORT in 'install') need to be built *together* to generate fully-functional KDE4WorkspaceConfig.cmake. The only workaround for us - Gentoo KDE maintainers would be to hack build system to get rid of this mechanism unfortunately. Hence following questions: - what policies are in question, when some library in kdebase-workspace is promoted to/removed from 'KDE4Workspace unit? Right now it's every library installed from kdeworkspace which also installs headers, i.e. which is supposed to be used by others. The question really is about, is it supposed to be added there just when needed and how often such changes are going to happen? I guess not too often, but we don't have policies about how fast and how many things may be added. - is it considered to split KDE4Workspace logical unit in just per library/package basis? Not that I know of. So that for example libplasmaclock would build and install its own cmake module, libkworkspace its own, etc. Of course it is always nice tro have it as modular as possible (while keeping it nice and clean to read). So if there are some easy things to do to make your work easier I'd happily accept patches. It would still preserve it's main functionality (out-of-the-box library finding) and it would at least allow us (and maybe some other distribution packagers) to build KDE4 packages without thoroughly hacking build system. I understand the issue. To have a KDE4WorkspaceConfig.cmake, you need to install it completely. YOu don't want to do it but instead do it separately. I think the correct solution would be to have separate FindKScreenSaver.cmake, FindKPlasmaSomething.cmake etc. files, and they could be installed additionally and used to the complete FindKDE4Workspace.cmake. So, IMO this would be correct and clean, but at the same time also some additional work. You could also use a modified (old-style) FindKDE4Workspace.cmake file, which does find_library() for all the different libs, and then you would have these libs set whioch have been actually found. I'm not sure what a good solution is. I would understand if you would say you wan to install e.g. libkhtml separately, for kdeworkspace I'm not sure it makes that much sense. I mean, it's just a few small libraries. Did you follow the discussion on kde-core-devel ? http://lists.kde.org/?t=12299356391r=1w=2 The conclusion was basically that we (KDE) recommend not to split workspace into separate packages. Workspace exports the following libraries: taskmanager kworkspace solidcontrolifaces solidcontrol processui lsofui plasmaclock nepomukqueryclient nepomukquery kscreensaver weather_ion kwineffects kdecorations ksgrd kephal Having each of them as a separate package really doesn't make a lot of sense. Can you come up with a split into maybe 3 or 4 packages which make sense (i.e. a plasma one, a nepomuk one, etc.) ? 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
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: 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
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Alexander Neundorf wrote:
On Tuesday 09 December 2008, Brad King wrote:
Brad King wrote:
Brad King wrote:
Perhaps you can avoid this by using PATH_SUFFIXES on the inner
find_package call in your find-modules:
find_package(KFoo NO_MODULE PATH_SUFFIXES cmake)
Then you can just always install to cmake/kfoo. Once a version of
CMake supporting this location is required in the future this suffix
can be removed.
Oops, nevermind. The PATH_SUFFIXES get appended to each generated path,
not to each prefix.
I think you'll just have to require 2.6.3 if you want to move the files
from kfoo/cmake to cmake/kfoo.
No chance, it's not released yet, and people just complained enough that we
required 2.6.2, and we are about to freeze:
http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule
Fortunately there is a pretty simple patch to 2.6.2 we can give to
distribution maintainers who want this to work to keep their system's clean.
I've included it below.
-Brad
diff -cp -r cmake-2.6.2-orig/Source/cmFindPackageCommand.cxx
cmake-2.6.2/Source/cmFindPackageCommand.cxx
*** cmake-2.6.2-orig/Source/cmFindPackageCommand.cxx2008-09-24
14:34:35.0 -0400
--- cmake-2.6.2/Source/cmFindPackageCommand.cxx 2008-12-18 09:09:25.0
-0500
*** cmFindPackageCommand::cmFindPackageComma
*** 218,223
--- 218,224
UNIX (U), or Apple (A) conventions.\n
prefix/ (W)\n
prefix/(cmake|CMake)/ (W)\n
+ prefix/(share|lib)/cmake/name*/ (U)\n
prefix/(share|lib)/name*/ (U)\n
prefix/(share|lib)/name*/(cmake|CMake)/ (U)\n
On systems supporting OS X Frameworks and Application Bundles
*** bool cmFindPackageCommand::SearchPrefix(
*** 1710,1715
--- 1711,1730
common.push_back(lib);
common.push_back(share);
+ // PREFIX/(share|lib)/cmake/(Foo|foo|FOO).*/
+ {
+ cmFindPackageFileList lister(this);
+ lister
+ / cmFileListGeneratorFixed(prefix)
+ / cmFileListGeneratorEnumerate(common)
+ / cmFileListGeneratorFixed(cmake)
+ / cmFileListGeneratorProject(this-Names);
+ if(lister.Search())
+ {
+ return true;
+ }
+ }
+
// PREFIX/(share|lib)/(Foo|foo|FOO).*/
{
cmFindPackageFileList lister(this);
___
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
Hi, On Thursday 18 December 2008, Maciej Mrozowski wrote: On Tuesday 09 of December 2008 01:42:14 Alexander Neundorf wrote: [...] Hi I have some questions related to mentioned changes in KDE4 build system. Introducing these methods will surely make it possible to keep CMake modules easier to maintain in the future as it should even effectively eliminate the need of FindXXX.cmake files for cmake-controlled libraries. And while this change is very good in general and I'm all for it - explicitly merging all workspace libraries in one logical unit (KDE4Workspace) effectively killed our automatic package building facility in Gentoo - the one that relies on splitting packages at library/application level. (so far it affects only some additional kdeartwork/kdetoys modules, but it's supposed to eventually spread everywhere I guess). The problem is - all workspace library targets (those with EXPORT in 'install') need to be built *together* to generate fully-functional KDE4WorkspaceConfig.cmake. The only workaround for us - Gentoo KDE maintainers would be to hack build system to get rid of this mechanism unfortunately. Hence following questions: - what policies are in question, when some library in kdebase-workspace is promoted to/removed from 'KDE4Workspace unit? Right now it's every library installed from kdeworkspace which also installs headers, i.e. which is supposed to be used by others. The question really is about, is it supposed to be added there just when needed and how often such changes are going to happen? I guess not too often, but we don't have policies about how fast and how many things may be added. - is it considered to split KDE4Workspace logical unit in just per library/package basis? Not that I know of. So that for example libplasmaclock would build and install its own cmake module, libkworkspace its own, etc. Of course it is always nice tro have it as modular as possible (while keeping it nice and clean to read). So if there are some easy things to do to make your work easier I'd happily accept patches. It would still preserve it's main functionality (out-of-the-box library finding) and it would at least allow us (and maybe some other distribution packagers) to build KDE4 packages without thoroughly hacking build system. I understand the issue. To have a KDE4WorkspaceConfig.cmake, you need to install it completely. YOu don't want to do it but instead do it separately. I think the correct solution would be to have separate FindKScreenSaver.cmake, FindKPlasmaSomething.cmake etc. files, and they could be installed additionally and used to the complete FindKDE4Workspace.cmake. So, IMO this would be correct and clean, but at the same time also some additional work. You could also use a modified (old-style) FindKDE4Workspace.cmake file, which does find_library() for all the different libs, and then you would have these libs set whioch have been actually found. I'm not sure what a good solution is. I would understand if you would say you wan to install e.g. libkhtml separately, for kdeworkspace I'm not sure it makes that much sense. I mean, it's just a few small libraries. Alex P.S. nice that you come up with this here on the list :-) ___ 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
Alexander Neundorf wrote: On Thursday 18 December 2008, Brad King wrote: Fortunately there is a pretty simple patch to 2.6.2 we can give to distribution maintainers who want this to work to keep their system's clean. I've included it below. Hmm, but I can't test for it. Right now I do if(cmake = 2.6.3) install( to lib/cmake/foo) else install( to lib/foo/cmake) endif Which means that if somebody has built KDE with 2.6.3, then he needs 2.6.3 to build other software using it. I'm not sure this patch helps a lot. Or is it time for a 2.6.2.1 ? I meant that the distro maintainers could patch both CMake 2.6.2 and their KDE 4.2 package to tuck these things down in lib/cmake/foo. This just provides a way for distro maintainers to keep things clean for themselves without bumping requirements for anyone or rushing the 2.6.3 release. -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
Alexander Neundorf wrote: To have a KDE4WorkspaceConfig.cmake, you need to install it completely. YOu don't want to do it but instead do it separately. I think the correct solution would be to have separate FindKScreenSaver.cmake, FindKPlasmaSomething.cmake etc. files, and they could be installed additionally and used to the complete FindKDE4Workspace.cmake. So, IMO this would be correct and clean, but at the same time also some additional work. You could also use a modified (old-style) FindKDE4Workspace.cmake file, which does find_library() for all the different libs, and then you would have these libs set whioch have been actually found. I'm not sure what a good solution is. I would understand if you would say you wan to install e.g. libkhtml separately, for kdeworkspace I'm not sure it makes that much sense. I mean, it's just a few small libraries. Since this is for Gentoo packaging then if a piece of KDE4Workspace is installed we know where it will be. 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. -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 Tuesday 09 of December 2008 01:42:14 Alexander Neundorf wrote: [...] Hi I have some questions related to mentioned changes in KDE4 build system. Introducing these methods will surely make it possible to keep CMake modules easier to maintain in the future as it should even effectively eliminate the need of FindXXX.cmake files for cmake-controlled libraries. And while this change is very good in general and I'm all for it - explicitly merging all workspace libraries in one logical unit (KDE4Workspace) effectively killed our automatic package building facility in Gentoo - the one that relies on splitting packages at library/application level. (so far it affects only some additional kdeartwork/kdetoys modules, but it's supposed to eventually spread everywhere I guess). The problem is - all workspace library targets (those with EXPORT in 'install') need to be built *together* to generate fully-functional KDE4WorkspaceConfig.cmake. The only workaround for us - Gentoo KDE maintainers would be to hack build system to get rid of this mechanism unfortunately. Hence following questions: - what policies are in question, when some library in kdebase-workspace is promoted to/removed from 'KDE4Workspace unit? The question really is about, is it supposed to be added there just when needed and how often such changes are going to happen? - is it considered to split KDE4Workspace logical unit in just per library/package basis? So that for example libplasmaclock would build and install its own cmake module, libkworkspace its own, etc. It would still preserve it's main functionality (out-of-the-box library finding) and it would at least allow us (and maybe some other distribution packagers) to build KDE4 packages without thoroughly hacking build system. It it's not considered, how we could handle this problem properly? (provided merging KDE4 workspace libraries is the least attractive option as creating those logical units may spread to other KDE components in a future, like for kdenetwork etc) -- regards MM -- A moze lepiej wziac prysznic we dwojke - oszczedzaj wode! http://video.interia.pl/obejrzyj,film,104059 ___ 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 Wednesday 10 December 2008, Modestas Vainius wrote:
Hello,
trečiadienis 10 Gruodis 2008, Alexander Neundorf rašė:
FindKDE4Internal.cmake (this one we can change) can then load the
target-export file. Which is right now in the same directory as itself.
If it's in lib, it has to find it.
1) I would prefer this one. Load target exports from Config.cmake itself.
If you implemented pimlibs and workspace the same way, you would not need
any FindKdepimlibs and FindKDE4Workspace anymore.
In KDELibsConfig.cmake:
get_filename_component(_config_dir ${CMAKE_CURRENT_LIST_FILE} PATH)
include(${_config_dir}/KDELibsLibraryTargets.cmake)
This doesn't change anything.
It doesn't matter whether we have to find the Config.cmake file or the
target-exports file from the FindKDE4Internal.cmake
In both cases FindKDE4Internal.cmake has been found based on the output from
kde4-config, so they belong together.
Once we start searching again in FindKDE4Internal.cmake, we have to make sure
to also find the right next file.
This has to in some way involve kde4-config again I think.
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
Hello, trečiadienis 10 Gruodis 2008, Alexander Neundorf rašė: This doesn't change anything. It doesn't matter whether we have to find the Config.cmake file or the target-exports file from the FindKDE4Internal.cmake In both cases FindKDE4Internal.cmake has been found based on the output from kde4-config, so they belong together. FindKDE4Internal.cmake: set (CMAKE_PREFIX_PATH `kde4-config --prefix`) ? (simplified version, with kde4-config found the same way FindKDE4 did it) find_package(foo) -- Modestas Vainius [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ 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 Tuesday 09 of December 2008 01:42:14 Alexander Neundorf wrote:
Hi,
if you are working on a module which uses kdepimlibs, please update both
kdelibs/cmake/modules/ and kdepimlibs/
Hello
I noticed those files are installed in
${PREFIX}/${LIBDIR}/KDE4Workspace/cmake/KDE4WorkspaceConfig.cmake
${PREFIX}/${LIBDIR}/KDE4Workspace/cmake/KDE4WorkspaceLibraryTargets-
release.cmake
${PREFIX}/${LIBDIR}/KDE4Workspace/cmake/KDE4WorkspaceLibraryTargets.cmake
Is this valid location? (why not with the rest cmake modules, in
${PREFIX}/${SHAREDIR}/apps/cmake/)
Cheers
--
regards
MM
--
Wygraj telefon komorkowy!
Sprawdz http://link.interia.pl/f1fc0
___
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
Hello,
antradienis 09 Gruodis 2008, Maciej Mrozowski rašė:
I noticed those files are installed in
${PREFIX}/${LIBDIR}/KDE4Workspace/cmake/KDE4WorkspaceConfig.cmake
${PREFIX}/${LIBDIR}/KDE4Workspace/cmake/KDE4WorkspaceLibraryTargets-
release.cmake
${PREFIX}/${LIBDIR}/KDE4Workspace/cmake/KDE4WorkspaceLibraryTargets.cmake
Is this valid location? (why not with the rest cmake modules, in
${PREFIX}/${SHAREDIR}/apps/cmake/)
I agree. Is this going to become a common practice to clutter /usr/lib
namespace for each module just for cmake files? They are /usr/share material
and we already have apps/cmake. Whats is wrong with placing those files to
e.g. kdelibs DATA/apps/cmake/configs (preserve the path the same way you
preserve KDElibs version and that's it) instead of such weird paths?
--
Modestas Vainius [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
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 09.12.08 11:47:47, Modestas Vainius wrote:
Hello,
antradienis 09 Gruodis 2008, Maciej Mrozowski rašė:
I noticed those files are installed in
${PREFIX}/${LIBDIR}/KDE4Workspace/cmake/KDE4WorkspaceConfig.cmake
${PREFIX}/${LIBDIR}/KDE4Workspace/cmake/KDE4WorkspaceLibraryTargets-
release.cmake
${PREFIX}/${LIBDIR}/KDE4Workspace/cmake/KDE4WorkspaceLibraryTargets.cmake
Is this valid location? (why not with the rest cmake modules, in
${PREFIX}/${SHAREDIR}/apps/cmake/)
I agree. Is this going to become a common practice to clutter /usr/lib
namespace for each module just for cmake files? They are /usr/share material
and we already have apps/cmake. Whats is wrong with placing those files to
e.g. kdelibs DATA/apps/cmake/configs (preserve the path the same way you
preserve KDElibs version and that's it) instead of such weird paths?
Because /usr/share is for non-platform specific data and those files
contain platform specific information (in particular they contain paths to
things like the library files and headers). Such platform specific stuff is
put into libdir. These files are the cmake equivalent of .pc files, which
also reside in /usr/lib.
Andreas
--
Today is what happened to yesterday.
___
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
Hello, antradienis 09 Gruodis 2008, Andreas Pakulat rašė: Because /usr/share is for non-platform specific data and those files contain platform specific information (in particular they contain paths to things like the library files and headers). Such platform specific stuff is put into libdir. These files are the cmake equivalent of .pc files, which also reside in /usr/lib. Okay, but then I wouldn't mind e.g. /usr/lib/kde4/cmake or something similar, just please do not pollute /usr/lib namespace directly. Likewise, pkg-config has /usr/lib/pkgconfig. -- Modestas Vainius [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ 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 Tuesday 09 of December 2008 11:23:18 Modestas Vainius wrote: Okay, but then I wouldn't mind e.g. /usr/lib/kde4/cmake or something similar, just please do not pollute /usr/lib namespace directly. Likewise, pkg-config has /usr/lib/pkgconfig. In my opinion /usr/lib/cmake/ would be fine to place those files - even without creating subdirs inside like KdepimLibs and similar. -- regards MM -- Drogowa Mapa Polski GPS w Twoim telefonie! Pobierz http://link.interia.pl/f1fc9 ___ 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 09.12.08 12:23:18, Modestas Vainius wrote: Hello, antradienis 09 Gruodis 2008, Andreas Pakulat rašė: Because /usr/share is for non-platform specific data and those files contain platform specific information (in particular they contain paths to things like the library files and headers). Such platform specific stuff is put into libdir. These files are the cmake equivalent of .pc files, which also reside in /usr/lib. Okay, but then I wouldn't mind e.g. /usr/lib/kde4/cmake or something similar, just please do not pollute /usr/lib namespace directly. Likewise, pkg-config has /usr/lib/pkgconfig. Thats not possible, because cmake won't find the files. See the find_package section in man cmake, specifically about the Config mode. Andreas -- Everything will be just tickety-boo today. ___ 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
Hello,
antradienis 09 Gruodis 2008, Andreas Pakulat rašė:
Because /usr/share is for non-platform specific data and those files
contain platform specific information (in particular they contain paths to
things like the library files and headers). Such platform specific stuff is
put into libdir. These files are the cmake equivalent of .pc files, which
also reside in /usr/lib.
By the way,
KDELibsDependencies.cmake
KDELibsLibraryTargets*.cmake
are in ${DATA_INSTALL_DIR}/cmake/modules (i.e. /usr/share). So these are not
platform specific while similar kdepimlibs and workspace stuff are?
--
Modestas Vainius [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
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
Hello,
antradienis 09 Gruodis 2008, Andreas Pakulat rašė:
Thats not possible, because cmake won't find the files. See the
find_package section in man cmake, specifically about the Config mode.
e.g. FindKDE4Workspace.cmake has:
find_package(KDE4Workspace QUIET NO_MODULE PATHS
${KDE4_LIB_DIR}/KDE4Workspace/cmake )
replace with:
find_package(KDE4Workspace QUIET NO_MODULE PATHS ${PLUGIN_INSTALL_DIR}/cmake )
or ${KDE4_LIB_DIR}/cmakeconfigs or ${KDE4_LIB_DIR}/cmake whatever you choose.
--
Modestas Vainius [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
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 Tuesday 09 of December 2008 11:23:18 Modestas Vainius wrote: Okay, but then I wouldn't mind e.g. /usr/lib/kde4/cmake or something similar, just please do not pollute /usr/lib namespace directly. Likewise, pkg-config has /usr/lib/pkgconfig. In my opinion /usr/lib/cmake/ would be fine to place those files - even without creating subdirs inside like KdepimLibs and similar. Many projects have a /usr/lib/name[-version] directory containing platform-specific data for the package. Placement of the files near to the libraries in the installation is a *feature* of the find_package command. It avoids all problems with multiple installations and multiple versions. The command magically finds the files burried in the installation instead of in some central place which can have conflicts. Furthermore, the relative path from the config files to the libraries remains fixed no matter where the package is installed. This ensures that the locations reported by the file are correct with no special packaging or versioning work. -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 Tuesday 09 of December 2008 17:38:33 Brad King wrote:
Maciej Mrozowski wrote:
On Tuesday 09 of December 2008 11:23:18 Modestas Vainius wrote:
Okay, but then I wouldn't mind e.g. /usr/lib/kde4/cmake or something
similar, just please do not pollute /usr/lib namespace directly.
Likewise, pkg-config has /usr/lib/pkgconfig.
In my opinion /usr/lib/cmake/ would be fine to place those files - even
without creating subdirs inside like KdepimLibs and similar.
Many projects have a /usr/lib/name[-version] directory containing
platform-specific data for the package.
Placement of the files near to the libraries in the installation is a
*feature* of the find_package command. It avoids all problems with
multiple installations and multiple versions. The command magically
finds the files burried in the installation instead of in some central
place which can have conflicts. Furthermore, the relative path from the
config files to the libraries remains fixed no matter where the package
is installed. This ensures that the locations reported by the file are
correct with no special packaging or versioning work.
I agree it may be very helpful, it just makes libdir look a bit cluttered.
On Gentoo we used to handle library dependencies in similar fashion. As we
split KDE packages (by disabling other cmake targets, with some explicit
exceptions, inter-module dependencies would need some love though, some
packages fails to build in parallel mode, with - j3 for example, as cmake
itself handles parallel builds well) - we can export dependencies to file,
save them on disk, and inject them in CMakeLists.txt in packages that make use
of them. This may be considered a hack, but it's at least upstream-independent
and the most important - we can decide where to put those .pc files.
** adding out target to cmake - create dependency file
save_library_dependencies() {
local depsfile=${T}/${PN}:${SLOT}
echo Saving library dependendencies in ${depsfile##*/}
echo EXPORT_LIBRARY_DEPENDENCIES(\${depsfile}\)
${S}/CMakeLists.txt
|| \
die Failed to save the library dependencies.
}
** install command - put where we want it
install_library_dependencies() {
local depsfile=${T}/${PN}:${SLOT}
echo Installing library dependendencies as ${depsfile##*/}
insinto /var/lib/kde
doins ${depsfile} || die Failed to install library dependencies.
}
** inject specified dependencies (file names in KMLOADLIBS) in package's
CMakeLists.txt
load_library_dependencies() {
local pn i depsfile
echo Injecting library dependendencies from '${KMLOADLIBS}'
i=0
for pn in ${KMLOADLIBS} ; do
((i++))
depsfile=/var/lib/kde/${pn}:${SLOT}
[[ -r ${depsfile} ]] || die Depsfile '${depsfile}' not
accessible. You
probably need to reinstall ${pn}.
sed -i -e ${i}iINCLUDE(\${depsfile}\) ${S}/CMakeLists.txt
|| \
die Failed to include library dependencies for ${pn}
done
}
Example file with dependency is attached (it is versioned as well, but in our
nomenclature).
As far as hack this is, it's quite convenient way to do it nearly
automatically for every package we want without manually playing with
CMakeLists.txt files.
No idea whether anyone else would like to use this idea, just throwing it
here.
--
regards
MM
--
W naszym konkursie SAM wybierasz sobie nagrode!
Sprawdz http://link.interia.pl/f1fcc
# Generated by CMake 2.6-patch 2
IF(${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} GREATER 2.4)
# Information for CMake 2.6 and above.
SET(akonadi-kabc_LIB_DEPENDS
general;akonadi-kde;general;/usr/lib64/qt4/libQtGui.so;general;kdecore;)
SET(akonadi-kde_LIB_DEPENDS
general;solid;general;/usr/lib64/qt4/libQtNetwork.so;general;/usr/lib64/qt4/libQtDBus.so;general;/usr/lib64/qt4/libQtSql.so;general;kdeui;general;kio;general;/usr/lib64/libakonadiprotocolinternals.so;)
SET(akonadi-kmime_LIB_DEPENDS
general;akonadi-kde;general;kmime;general;/usr/lib64/qt4/libQtGui.so;general;kdecore;general;kio;)
SET(gpgmepp-pthread_LIB_DEPENDS
general;/usr/lib64/libgpgme-pthread.so;general;/usr/lib64/libpthread.so;general;/usr/lib64/libgpg-error.so;)
SET(gpgmepp_LIB_DEPENDS
general;/usr/lib64/libgpgme.so;general;/usr/lib64/libgpg-error.so;)
SET(kabc_LIB_DEPENDS
general;kresources;general;kldap;general;kdeui;general;kdecore;)
SET(kabc_directory_LIB_DEPENDS
general;kio;general;kabc;general;kresources;)
SET(kabc_file_LIB_DEPENDS
general;/usr/lib64/qt4/libQtGui.so;general;kdecore;general;kabc;general;kabc_file_core;general;kresources;)
SET(kabc_file_core_LIB_DEPENDS
general;kio;general;kabc;general;kcal;general;kresources;)
SET(kabc_ldapkio_LIB_DEPENDS
general;kio;general;kabc;general;kldap;general;kresources;)
SET(kabc_net_LIB_DEPENDS
Re: changes to how kdepimlibs and kdebase/workspace are installed and found
Hello, antradienis 09 Gruodis 2008, Brad King rašė: Many projects have a /usr/lib/name[-version] directory containing platform-specific data for the package. Some do, some do not. Placement of the files near to the libraries in the installation is a *feature* of the find_package command. /usr/lib/liba.so.1.0.0 /usr/lib/liba.so.1 /usr/lib/liba.so /usr/lib/A/cmake/AConfig.cmake /usr/lib/libb.so.2.0.0 /usr/lib/libb.so.2 /usr/lib/libb.so /usr/lib/B/cmake/BConfig.cmake now multiply this by the number of libraries usually installed on the system. Sorry, but I call this /usr/lib pollution. You may not be violating FHS but you're sort of violating spirit of it. What saves the day a bit is that /usr/lib/liba.so /usr/lib/A/cmake/AConfig.cmake can stay in the development package which end users usually do not have installed. It avoids all problems with multiple installations and multiple versions. It may be, but at least the current KDE solution does not support development stuff of multiple versions under the same prefix. The command magically finds the files burried in the installation instead of in some central place which can have conflicts. instead of prefix/(share|lib)/name*/(cmake|CMake)/ you can also search for prefix/(share|lib)/cmake/name*/ or prefix/(share| lib)/cmake/name*Config.cmake. No conflicts. Furthermore, the relative path from the config files to the libraries remains fixed no matter where the package is installed. Yeah, it also remains fixed if you use: /usr/lib/liba.so.1.0.0 /usr/lib/liba.so.1 /usr/lib/liba.so /usr/lib/cmake/A/AConfig.cmake or just /usr/lib/cmake/AConfig.cmake after s#/usr/lib/## liba.so.1.0.0 liba.so.1 liba.so cmake/A/AConfig.cmake or just cmake/AConfig.cmake Looks pretty fixed to me. So I really want find_package() to support /usr/lib/cmake search path as an alternative search path. Please give distributors a choice. -- Modestas Vainius [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ 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
Modestas Vainius wrote: Hello, antradienis 09 Gruodis 2008, Brad King rae.: Many projects have a /usr/lib/name[-version] directory containing platform-specific data for the package. Some do, some do not. Placement of the files near to the libraries in the installation is a *feature* of the find_package command. /usr/lib/liba.so.1.0.0 /usr/lib/liba.so.1 /usr/lib/liba.so /usr/lib/A/cmake/AConfig.cmake /usr/lib/libb.so.2.0.0 /usr/lib/libb.so.2 /usr/lib/libb.so /usr/lib/B/cmake/BConfig.cmake now multiply this by the number of libraries usually installed on the system. Sorry, but I call this /usr/lib pollution. You may not be violating FHS but you're sort of violating spirit of it. What saves the day a bit is that /usr/lib/liba.so /usr/lib/A/cmake/AConfig.cmake can stay in the development package which end users usually do not have installed. It avoids all problems with multiple installations and multiple versions. It may be, but at least the current KDE solution does not support development stuff of multiple versions under the same prefix. The command magically finds the files burried in the installation instead of in some central place which can have conflicts. instead of prefix/(share|lib)/name*/(cmake|CMake)/ you can also search for prefix/(share|lib)/cmake/name*/ or prefix/(share| lib)/cmake/name*Config.cmake. No conflicts. Furthermore, the relative path from the config files to the libraries remains fixed no matter where the package is installed. Yeah, it also remains fixed if you use: /usr/lib/liba.so.1.0.0 /usr/lib/liba.so.1 /usr/lib/liba.so /usr/lib/cmake/A/AConfig.cmake or just /usr/lib/cmake/AConfig.cmake after s#/usr/lib/## liba.so.1.0.0 liba.so.1 liba.so cmake/A/AConfig.cmake or just cmake/AConfig.cmake Looks pretty fixed to me. So I really want find_package() to support /usr/lib/cmake search path as an alternative search path. Please give distributors a choice. When I first designed the find_package search procedure I proposed prefix/(share|lib)/cmake/name* (see http://www.cmake.org/Bug/view.php?id=3659, 2006-08-25 10:04) just as you suggest. The idea was that packages that already have a lib/name directory can put all their files together (including the cmake related files), but others can use lib/cmake/name* if they prefer. Later Alex convinced me that providing two places is confusing. I agree that cluttering /usr/lib with directories just for this one purpose is not pretty. I'll look at updating CMake to search the above locations too. -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
Brad King wrote: When I first designed the find_package search procedure I proposed prefix/(share|lib)/cmake/name* (see http://www.cmake.org/Bug/view.php?id=3659, 2006-08-25 10:04) just as you suggest. The idea was that packages that already have a lib/name directory can put all their files together (including the cmake related files), but others can use lib/cmake/name* if they prefer. Later Alex convinced me that providing two places is confusing. I agree that cluttering /usr/lib with directories just for this one purpose is not pretty. I'll look at updating CMake to search the above locations too. I've fixed this in CMake HEAD: /cvsroot/CMake/CMake/Source/cmFindPackageCommand.cxx,v -- Source/cmFindPackageCommand.cxx new revision: 1.52; previous revision: 1.51 We'll include it in the 2.6 release branch. -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
Hello,
antradienis 09 Gruodis 2008, Brad King rašė:
I've fixed this in CMake HEAD:
/cvsroot/CMake/CMake/Source/cmFindPackageCommand.cxx,v --
Source/cmFindPackageCommand.cxx
new revision: 1.52; previous revision: 1.51
Thank you for such quick response and fix. Now I wish Alex could add support
for this path to KDE. /usr/lib/Kdepimlibs and /usr/lib/KDE4Workspace currently
contains only cmake stuff which are found via
cmake/modules/Find{Kdepimlibs,KDE4Workspace}.cmake anyway. So it is easy to
workaround lack of native cmake support for this path in 2.6.2.
--
Modestas Vainius [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
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 Tuesday 09 December 2008, Modestas Vainius wrote:
Hello,
antradienis 09 Gruodis 2008, Andreas Pakulat rašė:
Because /usr/share is for non-platform specific data and those files
contain platform specific information (in particular they contain paths
to things like the library files and headers). Such platform specific
stuff is put into libdir. These files are the cmake equivalent of .pc
files, which also reside in /usr/lib.
By the way,
KDELibsDependencies.cmake
KDELibsLibraryTargets*.cmake
are in ${DATA_INSTALL_DIR}/cmake/modules (i.e. /usr/share). So these are
not platform specific while similar kdepimlibs and workspace stuff are?
No, they should also be in lib/ somewhere ideally.
They are where they are because
1) that's where I put them when I started with this more than two years ago
and I wasn't aware of that issue
2) nobody complained until now
3) cmake supports that Config.cmake file search just since 2.6.0, so with
2.4.x we had to use something different (which is what we have now)
4) FindKDE4.cmake comes with cmake and has to find FindKDE4Internal.cmake,
which then actually finds all the other things. Having it in the same
directory as FindKDE4Internal.cmake is a very easy and reliable way to do it.
So, you are right, ideally it should be under lib/ too.
I'm just not sure if I should change that now.
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
On Tuesday 09 December 2008, Modestas Vainius wrote:
Hello,
antradienis 09 Gruodis 2008, Andreas Pakulat rašė:
Thats not possible, because cmake won't find the files. See the
find_package section in man cmake, specifically about the Config mode.
e.g. FindKDE4Workspace.cmake has:
find_package(KDE4Workspace QUIET NO_MODULE PATHS
${KDE4_LIB_DIR}/KDE4Workspace/cmake )
replace with:
find_package(KDE4Workspace QUIET NO_MODULE PATHS
${PLUGIN_INSTALL_DIR}/cmake )
or ${KDE4_LIB_DIR}/cmakeconfigs or ${KDE4_LIB_DIR}/cmake whatever you
choose.
They may all help in many cases, but more or less only by accident.
PLUGIN_INSTALL_DIR is the directory where the current project will install its
plugins to. If this is different from the place where kdelibs is installed
(which is in some cases) it doesn't work.
KDE4_LIB_DIR is the directory where the libraries from kdelibs are installed,
which can be different from the directory where kdebase was installed.
E.g. I
have /opt/qt-copy, /opt/kdesupport, /opt/kdelibs, /opt/kdepimlibs, /opt/kde4
(for most other things). It would break here. I'm sure especially slightly
external projects like koffice or maybe also kdevelop often do it in a
similar way.
So, we (KDE) will install these files into a place where cmake expects them
and not hack around that.
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
On Tuesday 09 December 2008, Modestas Vainius wrote:
Hello,
antradienis 09 Gruodis 2008, Brad King rašė:
I've fixed this in CMake HEAD:
/cvsroot/CMake/CMake/Source/cmFindPackageCommand.cxx,v --
Source/cmFindPackageCommand.cxx
new revision: 1.52; previous revision: 1.51
Thank you for such quick response and fix. Now I wish Alex could add
support for this path to KDE. /usr/lib/Kdepimlibs and
/usr/lib/KDE4Workspace currently contains only cmake stuff which are
found via
cmake/modules/Find{Kdepimlibs,KDE4Workspace}.cmake anyway. So it is easy to
workaround lack of native cmake support for this path in 2.6.2.
So we'll have to do something like:
if (${CMAKE_VERSION_MAJOR}.${CMAKE_VERSION_MINOR}.${CMAKE_VERSION_PATCH}
VERSION_GREATER 2.6.2)
set(configInstallDir ${LIB_INSTALL_DIR}/cmake/kfoo)
else ()
set(configInstallDir ${LIB_INSTALL_DIR}/kfoo/cmake)
endif ()
install(EXPORT ... DESTINATION ${configInstallDir})
Hmm, not nice, but if you really want it, I guess we'll do that.
Should we include the version number ?
set(configInstallDir ${LIB_INSTALL_DIR}/kfoo-x.y.z/cmake)
Brad: is this version number considered when specifying a minimum version for
the package or is it ignored and only a fooVersion.cmake file will be used ?
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
Hello, antradienis 09 Gruodis 2008, Alexander Neundorf rašė: So, you are right, ideally it should be under lib/ too. I'm just not sure if I should change that now. In my opinion, while you are at it, do it now once and for all. -- Modestas Vainius [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ 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
Hello,
antradienis 09 Gruodis 2008, Alexander Neundorf rašė:
if (${CMAKE_VERSION_MAJOR}.${CMAKE_VERSION_MINOR}.${CMAKE_VERSION_PATCH}
VERSION_GREATER 2.6.2)
set(configInstallDir ${LIB_INSTALL_DIR}/cmake/kfoo)
else ()
set(configInstallDir ${LIB_INSTALL_DIR}/kfoo/cmake)
endif ()
I would suggest to put this into macro to enable unified generation of
configInstallDir for any project.
--
Modestas Vainius [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
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
Alexander Neundorf wrote:
On Tuesday 09 December 2008, Modestas Vainius wrote:
Hello,
antradienis 09 Gruodis 2008, Brad King rašė:
I've fixed this in CMake HEAD:
/cvsroot/CMake/CMake/Source/cmFindPackageCommand.cxx,v --
Source/cmFindPackageCommand.cxx
new revision: 1.52; previous revision: 1.51
Thank you for such quick response and fix. Now I wish Alex could add
support for this path to KDE. /usr/lib/Kdepimlibs and
/usr/lib/KDE4Workspace currently contains only cmake stuff which are
found via
cmake/modules/Find{Kdepimlibs,KDE4Workspace}.cmake anyway. So it is easy to
workaround lack of native cmake support for this path in 2.6.2.
So we'll have to do something like:
if (${CMAKE_VERSION_MAJOR}.${CMAKE_VERSION_MINOR}.${CMAKE_VERSION_PATCH}
VERSION_GREATER 2.6.2)
set(configInstallDir ${LIB_INSTALL_DIR}/cmake/kfoo)
else ()
set(configInstallDir ${LIB_INSTALL_DIR}/kfoo/cmake)
endif ()
Unfortunately the version of CMake that is doing the *finding* needs to
be higher than 2.6.2 in order for the cmake/kfoo path to work. The
version doing the installing does not matter. Often they will be the
same cmake, but sometimes not.
Perhaps you can avoid this by using PATH_SUFFIXES on the inner
find_package call in your find-modules:
find_package(KFoo NO_MODULE PATH_SUFFIXES cmake)
Then you can just always install to cmake/kfoo. Once a version of CMake
supporting this location is required in the future this suffix can be
removed.
Should we include the version number ?
set(configInstallDir ${LIB_INSTALL_DIR}/kfoo-x.y.z/cmake)
or perhaps
set(configInstallDir ${LIB_INSTALL_DIR}/cmake/kfoo-x.y.z)
? Anyway, yes, I think the version number should be on the directory.
This will help support multiple KDE versions in the same prefix. Even
if that is not a design goal, having the version number in the path does
not affect CMake's ability to find the package. It may also give more
information when helping users remotely.
Brad: is this version number considered when specifying a minimum version for
the package or is it ignored and only a fooVersion.cmake file will be used ?
The latter. The directory name is purposely and completely ignored (for
various reasons I'll omit here). The FooConfigVersion.cmake files are
the only way to enforce version constraints.
I think you should put the version files in now. If an installation
doesn't have one, then versioned requests will not find anything because
there is no version file to say it supports a particular version. Once
you have installations distributed like this it will be hard to add
versioning later.
-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 Tuesday 09 December 2008, Modestas Vainius wrote: Hello, antradienis 09 Gruodis 2008, Alexander Neundorf rašė: So, you are right, ideally it should be under lib/ too. I'm just not sure if I should change that now. In my opinion, while you are at it, do it now once and for all. So: FindKDE4Internal.cmake is under share/. A KDELibsConfig.cmake would be under lib/. Theoretically it would be possible that in a networked install the share/ is used for different architectures, while the different hosts (Solaris, BSD, Linux) use separate lib/ directories. Right ? Would they all exist on one system, which different names, like libBSD/, libSunos/ etc. or would they be mounted accordingly, so that always only one of them is there, and its name is always lib/ ? The thing is, how do I find out from /opt/kde/share where my corresponding lib/ directory is ? I could install another (configured) file, which tells me the lib/ directory. But would this then still work for such a networked install ? 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
On Tuesday 09 December 2008, Modestas Vainius wrote:
Hello,
antradienis 09 Gruodis 2008, Alexander Neundorf rašė:
if (${CMAKE_VERSION_MAJOR}.${CMAKE_VERSION_MINOR}.${CMAKE_VERSION_PATCH}
VERSION_GREATER 2.6.2)
set(configInstallDir ${LIB_INSTALL_DIR}/cmake/kfoo)
else ()
set(configInstallDir ${LIB_INSTALL_DIR}/kfoo/cmake)
endif ()
I would suggest to put this into macro to enable unified generation of
configInstallDir for any project.
This would mean that the name and also the version number would have to be
available in a standard way, which is currently not the case.
And I don't want to hide simple things (otherwise they become magic).
Can there be any issues if somebody has a 2.6.2-built KDE and upgrades to
cmake 2.6.3 ?
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
Brad King wrote: Brad King wrote: Perhaps you can avoid this by using PATH_SUFFIXES on the inner find_package call in your find-modules: find_package(KFoo NO_MODULE PATH_SUFFIXES cmake) Then you can just always install to cmake/kfoo. Once a version of CMake supporting this location is required in the future this suffix can be removed. Oops, nevermind. The PATH_SUFFIXES get appended to each generated path, not to each prefix. I think you'll just have to require 2.6.3 if you want to move the files from kfoo/cmake to cmake/kfoo. -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
Brad King wrote: Perhaps you can avoid this by using PATH_SUFFIXES on the inner find_package call in your find-modules: find_package(KFoo NO_MODULE PATH_SUFFIXES cmake) Then you can just always install to cmake/kfoo. Once a version of CMake supporting this location is required in the future this suffix can be removed. Oops, nevermind. The PATH_SUFFIXES get appended to each generated path, not to each prefix. -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 Tuesday 09 December 2008, Brad King wrote:
Alexander Neundorf wrote:
On Tuesday 09 December 2008, Modestas Vainius wrote:
Hello,
antradienis 09 Gruodis 2008, Brad King rašė:
I've fixed this in CMake HEAD:
/cvsroot/CMake/CMake/Source/cmFindPackageCommand.cxx,v --
Source/cmFindPackageCommand.cxx
new revision: 1.52; previous revision: 1.51
Thank you for such quick response and fix. Now I wish Alex could add
support for this path to KDE. /usr/lib/Kdepimlibs and
/usr/lib/KDE4Workspace currently contains only cmake stuff which are
found via
cmake/modules/Find{Kdepimlibs,KDE4Workspace}.cmake anyway. So it is easy
to workaround lack of native cmake support for this path in 2.6.2.
So we'll have to do something like:
if (${CMAKE_VERSION_MAJOR}.${CMAKE_VERSION_MINOR}.${CMAKE_VERSION_PATCH}
VERSION_GREATER 2.6.2)
set(configInstallDir ${LIB_INSTALL_DIR}/cmake/kfoo)
else ()
set(configInstallDir ${LIB_INSTALL_DIR}/kfoo/cmake)
endif ()
Unfortunately the version of CMake that is doing the *finding* needs to
be higher than 2.6.2 in order for the cmake/kfoo path to work. The
I think that's ok.
If somebody installs it using 2.6.3 it should be ok to require that he's also
using = 2.6.3 for using it.
...
Should we include the version number ?
set(configInstallDir ${LIB_INSTALL_DIR}/kfoo-x.y.z/cmake)
or perhaps
set(configInstallDir ${LIB_INSTALL_DIR}/cmake/kfoo-x.y.z)
Yes.
? Anyway, yes, I think the version number should be on the directory.
This will help support multiple KDE versions in the same prefix. Even
if that is not a design goal, having the version number in the path does
not affect CMake's ability to find the package. It may also give more
information when helping users remotely.
Ok.
Brad: is this version number considered when specifying a minimum version
for the package or is it ignored and only a fooVersion.cmake file will be
used ?
The latter. The directory name is purposely and completely ignored (for
various reasons I'll omit here). The FooConfigVersion.cmake files are
the only way to enforce version constraints.
I think you should put the version files in now. If an installation
doesn't have one, then versioned requests will not find anything because
there is no version file to say it supports a particular version. Once
you have installations distributed like this it will be hard to add
versioning later.
So this will be my work in the next days :-)
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
Hello, antradienis 09 Gruodis 2008, Alexander Neundorf rašė: The thing is, how do I find out from /opt/kde/share where my corresponding lib/ directory is ? Why do you need to? If I'm not missing something, cmake itself should be able to do this for you. That's the whole point of those search paths in find_package(), isn't it? -- Modestas Vainius [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ 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 Tuesday 09 December 2008, Modestas Vainius wrote: Hello, antradienis 09 Gruodis 2008, Alexander Neundorf rašė: The thing is, how do I find out from /opt/kde/share where my corresponding lib/ directory is ? Why do you need to? If I'm not missing something, cmake itself should be able to do this for you. That's the whole point of those search paths in find_package(), isn't it? If somebody does find_package(KDE4) it first finds FindKDE4.cmake from the cmake module directory. This file uses kde4-config to find FindKDE4Internal.cmake. Up to here we shouldn't (better: can't) change things. FindKDE4Internal.cmake (this one we can change) can then load the target-export file. Which is right now in the same directory as itself. If it's in lib, it has to find it. 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
On Tuesday 09 December 2008, Brad King wrote: Brad King wrote: Brad King wrote: Perhaps you can avoid this by using PATH_SUFFIXES on the inner find_package call in your find-modules: find_package(KFoo NO_MODULE PATH_SUFFIXES cmake) Then you can just always install to cmake/kfoo. Once a version of CMake supporting this location is required in the future this suffix can be removed. Oops, nevermind. The PATH_SUFFIXES get appended to each generated path, not to each prefix. I think you'll just have to require 2.6.3 if you want to move the files from kfoo/cmake to cmake/kfoo. No chance, it's not released yet, and people just complained enough that we required 2.6.2, and we are about to freeze: http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule 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
Hello,
trečiadienis 10 Gruodis 2008, Alexander Neundorf rašė:
FindKDE4Internal.cmake (this one we can change) can then load the
target-export file. Which is right now in the same directory as itself. If
it's in lib, it has to find it.
1) I would prefer this one. Load target exports from Config.cmake itself. If
you implemented pimlibs and workspace the same way, you would not need any
FindKdepimlibs and FindKDE4Workspace anymore.
In KDELibsConfig.cmake:
get_filename_component(_config_dir ${CMAKE_CURRENT_LIST_FILE} PATH)
include(${_config_dir}/KDELibsLibraryTargets.cmake)
FindKDE4InstalL.cmake:
find_package(KDELibs NO_MODULE)
2) Store configInstallDir in KDELibsConfig.cmake itself, then in
FindKDE4Internal.cmake:
find_package(KDELibs NO_MODULE)
include(${KDELIBS_CONFIG_INSTALL_DIR}/KDELibsLibraryTargets.cmake)
3) In FindKDE4Internal.cmake:
find_package(KDELibs NO_MODULE)
get_filename_component(_config_dir ${KDELibs_CONFIG} PATH)
include(${_config_dir}/KDELibsLibraryTargets.cmake)
2) and 3) are based on cmake docs:
Since the file is provided by the package it already knows the location of
package contents. The full path to the configuration file is stored in the
cmake variable package_CONFIG.
--
Modestas Vainius [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
changes to how kdepimlibs and kdebase/workspace are installed and found
Hi, if you are working on a module which uses kdepimlibs, please update both kdelibs/cmake/modules/ and kdepimlibs/ If you are working on a module which uses some stuff from kdebase/workspace (i.e. kdeotys, kdeartwork, kdeplasma-addons), please update both kdelibs and kdebase. For both cases this should be really the last time, since now all the information for using these modules is provided by the respective module, and the FindKdepimLibs.cmake/FindKDE4Workspace.cmake is *very* simple now and loads only a file created and installed by that module (i.e. KdepimLibsConfig.cmake/KDE4WorkspaceConfig.cmake). This file contains settings like the install directories and libraries of that module, so they are available to other modules. In case kdepimlibs or kdeworkspace is not found (i.e if cmake complains e.g. about KdepimLibs_DIR), two things -set the environment variable CMAKE_PREFIX_PATH so that it points also to the install prefix of kdepimlibs/kdebase -try starting with a fresh build dir You can find more information in kdepimlibs/CMakeLists.txt and kdebase/workspace/CMakeLists.txt. I'm sorry for the inconvenience, but I hope with this change such chained updates won't be necessary any more. Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
