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
