Re: [Patch] introduce new cmake var KDE4_LIB_DESTINATION
On Thursday 14 February 2008, Alexander Neundorf wrote:
> Hi,
>
> On Thursday 14 February 2008, Christian Ehrlicher wrote:
> > Hi,
> >
> > following the discussion in 'Re: Getting rid of the LIB_INSTALL_DIR hack
> > on windows' (http://lists.kde.org/?t=12001561931&r=1&w=2) I created
> > a patch which introduces a new var KDE4_LIB_DESTINATION.
...
> Next option:
> We could also add
> set(INSTALL_TARGET_DEFAULT_ARGUMENTS RUNTIME DESTINATION bin COMPONENT User
> LIBRARY DESTINATION lib COMPONENT User
> ARCHIVE DESTINATION lib COMPONENT
> Devel )
>
> and then do
> install(TARGETS konsole kdecore kdeui ${INSTALL_TARGETS_DEFAULT_ARGUMENTS})
>
> Later on this could be extended once we require (or can optionally use, not
> sure about that) CMake 2.6 which supports library frameworks on OSX, they
> need even more locations.
I think I prefer this option. It works with cmake 2.4.5 and we will be able to
extend it later on. It kind of slightly breaks source compatibility on
Windows, but since we don't have an official release there this is no
problem.
A patch for this is attached. If we agree on this, I'd prefer if one of the
windows developers could apply it, after he made sure installing works
correctly on his system.
Comments ?
Alex
Index: FindKDE4Internal.cmake
===
--- FindKDE4Internal.cmake (revision 775564)
+++ FindKDE4Internal.cmake (working copy)
@@ -489,14 +489,7 @@
if (WIN32)
# use relative install prefix to avoid hardcoded install paths in cmake_install.cmake files
-# ok, this is more like a hack to get dll's installed into the same directory as the executables
-# without having to use the full syntax of INSTALL(TARGETS ...) everywhere.
-# LIB_INSTALL_DIR is set to a list of arguments, the first being the "default" destination
-# which is then overridden by the following three specialized destinations
- set(LIB_INSTALL_DIR "lib${LIB_SUFFIX}"
-RUNTIME DESTINATION "bin"
-LIBRARY DESTINATION "lib${LIB_SUFFIX}"
-ARCHIVE DESTINATION "lib${LIB_SUFFIX}" ) # The subdirectory relative to the install prefix where libraries will be installed (default is ${EXEC_INSTALL_PREFIX}/lib${LIB_SUFFIX})
+ set(LIB_INSTALL_DIR "lib${LIB_SUFFIX}" )# The subdirectory relative to the install prefix where libraries will be installed (default is ${EXEC_INSTALL_PREFIX}/lib${LIB_SUFFIX})
set(EXEC_INSTALL_PREFIX "" )# Base directory for executables and libraries
set(SHARE_INSTALL_PREFIX "share" ) # Base directory for files which go to share/
@@ -602,6 +595,31 @@
endif (WIN32)
+# The INSTALL_TARGETS_DEFAULT_ARGS variable should be used when libraries are installed.
+# The arguments are also ok for regular executables, i.e. executables which don't go
+# into sbin/ or libexec/, but for installing executables the basic syntax
+# INSTALL(TARGETS kate DESTINATION "${BIN_INSTALL_DIR}")
+# is enough, so using this variable there doesn't help a lot.
+# The variable must not be used for installing plugins.
+# Usage is like this:
+#install(TARGETS kdecore kdeui ${INSTALL_TARGETS_DEFAULT_ARGS} )
+#
+# This will install libraries correctly under UNIX, OSX and Windows (i.e. dll's go
+# into bin/.
+# Later on it will be possible to extend this for installing OSX frameworks
+# The COMPONENT Devel argument has the effect that static libraries belong to the
+# "Devel" install component. If we use this also for all install() commands
+# for header files, it will be possible to install
+# -everything: make install OR cmake -P cmake_install.cmake
+# -only the development files: cmake -DCOMPONENT=Devel -P cmake_install.cmake
+# -everything except the development files: cmake -DCOMPONENT=Unspecified -P cmake_install.cmake
+# This can then also be used for packaging with cpack.
+
+set(INSTALL_TARGETS_DEFAULT_ARGS RUNTIME DESTINATION "${BIN_INSTALL_DIR}"
+ LIBRARY DESTINATION "${LIB_INSTALL_DIR}"
+ ARCHIVE DESTINATION "${LIB_INSTALL_DIR}" COMPONENT Devel )
+
+
## add some more default search paths ###
# always search in the directory where cmake is installed
# and in the current installation prefix
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On Monday 28 January 2008, Brad King wrote:
> Andreas Pakulat wrote:
> > On 28.01.08 16:04:06, David Faure wrote:
> >> On Monday 28 January 2008, Andreas Pakulat wrote:
> >>> Opinions? Better Ideas?
> >>
> >> Does replacing -lsolid with ${KDE4_SOLID_LIBS} work?
> >> After all we already have those variables, so we can avoid -lfoo
> >> completely I think.
> >
> > Its not quite that easy. The thing is that -lsolid is produced my
> > cmake's export_library_dependencies() function. So we'd have to find all
> > uses of all KDE_XXX_LIBS variables that include -lsolid and then add
> > KDE_SOLID_LIBS to the target_link_libraries() call.
> >
> > And then again if compiling aborts with -lkparts or some other lib.
>
> It looks like export_library_dependencies is misused a bit. The command
Yes, but I noticed that quite late (you showed me the intended way to use it I
think august last year) and at that time the KDE developers were already used
to using these variables, so I didn't change it anymore.
...
> It is up to the project that calls export_library_dependencies to
> produce a variable containing the link directory. The user project
> should be able to do
>
>find_package(XXX REQUIRED)
>link_directories(${XXX_LIBRARY_DIRS})
>target_link_libraries(myexe zot)
Getting all the lib dirs to CMAKE_SOURCE_DIR/CMakeLists.txt, where
export_library_dependencies() is called has two problems:
-everybody who uses not the project-default install dir has to remember that
he has to do something so that his dir also ends up in the installed file
-getting information from some subdir to the parent dir is hard (easier with
2.6)
I think having export_library_dependencies() really export the install
location of the libraries would be a good thing (in the 2.6 part of the
created file).
I just noticed that export_library_deps() doesn't respect the OUTPUT_NAME
property of a library, exporting the full install location would also fix
this problem:
add_library(foo foo.c)
set_target_property(foo PROPERTIES OUTPUT_NAME notfoo)
add_library(bar bar.c)
target_link_libraries(bar foo)
export_library_dependencies(deps.cmake)
will have "foo" in it, although no libfoo.so will exist, so a project which
uses that file will not work.
Can you have a look at that ?
I can try to come up with a patch, but you can fix this much faster.
If you want I can create a bug report for the OUTPUT_NAME bug.
Alex
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
Alexander Neundorf wrote:
> On Monday 28 January 2008, Brad King wrote:
>> It is up to the project that calls export_library_dependencies to
>> produce a variable containing the link directory. The user project
>> should be able to do
>>
>>find_package(XXX REQUIRED)
>>link_directories(${XXX_LIBRARY_DIRS})
>>target_link_libraries(myexe zot)
>
> Getting all the lib dirs to CMAKE_SOURCE_DIR/CMakeLists.txt, where
> export_library_dependencies() is called has two problems:
> -everybody who uses not the project-default install dir has to remember that
> he has to do something so that his dir also ends up in the installed file
> -getting information from some subdir to the parent dir is hard (easier with
> 2.6)
Kitware projects have done it this way for years. Instead of trying to
send information from the subdirs to the top we send it the other way.
The top directories configure the install locations and tell the child
dirs where to install. Then the locations are placed in the config file
to be loaded by user projects. It is a bit of work for the developer,
but that is how we did it and how the export_library_dependencies
command was meant to be used.
CMake 2.6 provides a much better alternative as discussed below.
> I think having export_library_dependencies() really export the install
> location of the libraries would be a good thing (in the 2.6 part of the
> created file).
I don't think changing 2.6's export_library_dependencies command to use
full paths is the solution. It would only be redundant work for a
command I don't want people to use anymore (see below). The command
does not have access to the install locations of targets. The content
it produces was meant for use both from build trees and from install
trees. Changing it to use full install paths would break projects
depending on that capability (VTK, ITK, vxl, and ParaView at least).
Besides, how would someone using 2.6 to build their project deal with
kdelibs built and installed by 2.4? The paths would not be available.
How was this all working with 2.4? Do the effects of
CMAKE_LINK_OLD_PATHS completely solve the problem with 2.6? If so, that
means that some of the libraries were getting found and linked using
full paths. Otherwise the -L paths would not have been there before.
How are the full paths to some libraries getting passed to the user?
CMake 2.6 will provide full support for executables and libraries with
that install(EXPORT)/IMPORTED-target feature we designed last summer.
It is already working and tested in CMake HEAD.
I think the solution is to start using the new export/import feature
when 2.6 is released. As long as both the exporter and importer are
using 2.6 it will work well. If both are using 2.4 then the current
stuff can be used and will work as it does now. If the exporting
project is built with 2.6 and the importing project with 2.4 the current
approach should also continue to work. What remains is to try to
support exporting with 2.4 and importing with 2.6. For that case we
could just define CMAKE_LINK_OLD_PATHS in the old-style export.
Once this dual scheme is setup then you can start building pre-compiled
distributions with 2.6. Setup the installed config files to load the
new-style exports when the user uses 2.6 and the old-style exports when
the user uses 2.4. Then tell anyone that has too many problems with the
old-style exports to start using 2.6. Eventually when you drop support
for 2.4 you can just get rid of the old-style exports altogether.
-Brad
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Howto fix KDE4 Buildsystem with CMake CVS
On Saturday 16 February 2008, you wrote:
> Alexander Neundorf wrote:
> > On Monday 28 January 2008, Brad King wrote:
> >> It is up to the project that calls export_library_dependencies to
> >> produce a variable containing the link directory. The user project
> >> should be able to do
> >>
> >>find_package(XXX REQUIRED)
> >>link_directories(${XXX_LIBRARY_DIRS})
> >>target_link_libraries(myexe zot)
> >
> > Getting all the lib dirs to CMAKE_SOURCE_DIR/CMakeLists.txt, where
> > export_library_dependencies() is called has two problems:
> > -everybody who uses not the project-default install dir has to remember
> > that he has to do something so that his dir also ends up in the installed
> > file -getting information from some subdir to the parent dir is hard
> > (easier with 2.6)
>
> Kitware projects have done it this way for years. Instead of trying to
> send information from the subdirs to the top we send it the other way.
> The top directories configure the install locations and tell the child
> dirs where to install. Then the locations are placed in the config file
> to be loaded by user projects. It is a bit of work for the developer,
Basically we do the same, it's just that I can't guarantee that really all
subdirectories use these default install locations.
You can't compare Kitware and KDE in this regard, KDE has hundreds of
developers, many know only the basics of cmake, it has many many projects,
both in KDE svn and outside KDE svn, at the same time KDE doesn't have more
cmake-specialist man hours available than Kitware.
So the solution must be easy-to-use and very modular, and the cmake files must
look clean, if possible without special casing e.g. for different cmake
versions (if our buildfiles would be too complicated we would loose
contributors).
> but that is how we did it and how the export_library_dependencies
> command was meant to be used.
>
> CMake 2.6 provides a much better alternative as discussed below.
Yes, I know and I would like to use it, but I can't.
To use it KDE would have to require the appropriate CMake version, and this
won't happen before a non-beta version of CMake 2.6 is shipped by default by
the major distributions. So maybe in late summer or fall this year.
> > I think having export_library_dependencies() really export the install
> > location of the libraries would be a good thing (in the 2.6 part of the
> > created file).
>
> I don't think changing 2.6's export_library_dependencies command to use
> full paths is the solution. It would only be redundant work for a
> command I don't want people to use anymore (see below).
Yes, I know.
> The command does not have access to the install locations of targets.
I think it could find out via the InstallTargetGenerators in cmMakefile.
> The content
> it produces was meant for use both from build trees and from install
> trees. Changing it to use full install paths would break projects
> depending on that capability (VTK, ITK, vxl, and ParaView at least).
Oh, being usable from the build tree, I didn't think of this. This really
excludes the possibility to use the install location.
Except with even more special handling, like detecting whether the file is in
the build tree or installed and then doing different things :-/
There is still the problem with OUTPUT_NAME which is a real bug.
> Besides, how would someone using 2.6 to build their project deal with
> kdelibs built and installed by 2.4? The paths would not be available.
>
> How was this all working with 2.4? Do the effects of
> CMAKE_LINK_OLD_PATHS completely solve the problem with 2.6? If so, that
Actually I'd like to use the new style, since this will avoid the problems it
is supposed to avoid :-)
What do you think about putting
LINK_DIRECTORIES(${LIB_INSTALL_DIR})
into the installed file from kdelibs ?
I could do this. How are the directories added via LINK_DIRECTORIES() handled
when determining the order of the directories, which should still be required
e.g. for the rpath ?
This would work for most cases, except those where some library is installed
to some other directory.
> means that some of the libraries were getting found and linked using
> full paths. Otherwise the -L paths would not have been there before.
> How are the full paths to some libraries getting passed to the user?
Example:
find_library(KDE4_KHTML_LIBRARY NAMES khtml PATHS ${KDE4_LIB_INSTALL_DIR}
NO_DEFAULT_PATH )
set(KDE4_KHTML_LIBS ${khtml_LIB_DEPENDS} ${KDE4_KHTML_LIBRARY} )
so the depending library always has the full path.
> CMake 2.6 will provide full support for executables and libraries with
> that install(EXPORT)/IMPORTED-target feature we designed last summer.
> It is already working and tested in CMake HEAD.
>
> I think the solution is to start using the new export/import feature
> when 2.6 is released. As long as both the exporter and importer are
I can't, see above.
> using 2.6 it will work well.
Re: CMake check for create-resources
On Feb 15, 2008 11:43 PM, Alexander Neundorf <[EMAIL PROTECTED]> wrote:
> On Friday 15 February 2008, Sven Langkamp wrote:
> > On Wed, Feb 13, 2008 at 8:06 PM, Alexander Neundorf <[EMAIL PROTECTED]>
> >
> > wrote:
> > > On Wednesday 13 February 2008, you wrote:
> > > > On Feb 12, 2008 6:28 PM, Alexander Neundorf <[EMAIL PROTECTED]>
> wrote:
> > > > > On Tuesday 12 February 2008, Sven Langkamp wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I want to add a dependency for the create-resources package to
> > >
> > > KOffice,
> > >
> > > > > > which contains shared resources from the CREATE project.
> > > > > > How can I check if the package is installed? Note that the
> package
> > >
> > > only
> > >
> > > > > > contains data and no code.
> > > > >
> > > > > What does this package consist of and where is it typically
> installed
> > >
> > > ?
> > >
> > > > > You probably need to do something with find_path().
> > > >
> > > > On my system it's in /usr/share/create/ and it contains brush,
> pattern
> > >
> > > and
> > >
> > > > gradient files.
> > > >
> > > > I tried to put a FindCreateResources.cmake in koffice/cmake/modules,
> > > > but that doesn't work and is probably not even valid cmake code:
> > > >
> > > > if(CREATERESOURCES_INCLUDE_DIR)
> > > >
> > > > set(CREATERESOURCES_FOUND TRUE)
> > > >
> > > > else(CREATERESOURCES_INCLUDE_DIR)
> > > >
> > > > find_path( CREATERESOURCES_INCLUDE_DIR simple.kgr/usr/share/create/
> > > > ) if( CREATERESOURCES_INCLUDE_DIR )
> > > > set( CREATERESOURCES_FOUND TRUE )
> > > > endif( CREATERESOURCES_INCLUDE_DIR )
> > > > endif(CREATERESOURCES_INCLUDE_DIR)
> > > >
> > > > find_package(createresources REQUIRED) gives CMake Error:
> > > > createresources_DIR is not set. It must be set to the directory
> > >
> > > containing
> > >
> > > > createresourcesConfig.cmake in order to use createresources.
> > >
> > > The filename is FindCreateResources.cmake, so must use exact that
> case:
> > > find_package(CreateResources)
> >
> > Thanks, this worked.
> >
> > > I'd suggest to start simple:
> > >
> > > find_path( CREATERESOURCES_INCLUDE_DIR simple.kgr
> > >PATHS
> > > ${CMAKE_INSTALL_PREFIX}
> > > /usr /usr/local /usr/pkg
> > > /opt /opt/local /opt/csw
> > > PATH_SUFFIXES share/create )
> > >
> > > if( CREATERESOURCES_INCLUDE_DIR )
> > > set( CREATERESOURCES_FOUND TRUE )
> > > endif( CREATERESOURCES_INCLUDE_DIR )
> > >
> > > (with cmake cvs it wouldn't be necessary to list all these paths,
> there
> > > it has
> > > CMAKE_SYSTEM_PREFIX_PATH which has all these search prefixes)
> > >
> > > Does that project have a homepage ?
> >
> > Is there a way to see if the package was found? At the moment cmake
> runs,
> > but I don't get feedback from it.
>
> Yes.
> You can do the following:
>
> find_package(CreateResources)
>
> if(CREATERESOURCES_FOUND)
> message(STATUS "Create Resources found")
> endif(CREATERESOURCES_FOUND)
>
> or you can grep for CREATERES in CMakeCache.txt and see what it contains.
>
> Or you can do "make edit_cache" and check that way for
> CREATERESOURCES_INCLUDE_DIR
>
> or (even better) you can do the following in FindCreateResources.cmake:
>
> find_path(...)
>
> find_package_handle_standard_args(CreateResources DEFAULT_MSG
>
> CREATERESOURCES_INCLUDE_DIR)
>
>
> If you need to find more than one file, use find_path() for all of them
> and
> list the result variables in the find_package_handle_standard_args()
> macro.
> ( you can remove the if(CREATERESOURCES_INCLUDE_DIR)
> set(CREATE_RESOURCES_FOUND TRUE) then, this is handled by the macro
> above.
>
Works great. Thanks a lot for your help.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [Patch] introduce new cmake var KDE4_LIB_DESTINATION
Alexander Neundorf schrieb:
> On Thursday 14 February 2008, Alexander Neundorf wrote:
>> Hi,
>>
>> On Thursday 14 February 2008, Christian Ehrlicher wrote:
>>> Hi,
>>>
>>> following the discussion in 'Re: Getting rid of the LIB_INSTALL_DIR hack
>>> on windows' (http://lists.kde.org/?t=12001561931&r=1&w=2) I created
>>> a patch which introduces a new var KDE4_LIB_DESTINATION.
> ...
>> Next option:
>> We could also add
>> set(INSTALL_TARGET_DEFAULT_ARGUMENTS RUNTIME DESTINATION bin COMPONENT User
>> LIBRARY DESTINATION lib COMPONENT User
>> ARCHIVE DESTINATION lib COMPONENT
>> Devel )
>>
>> and then do
>> install(TARGETS konsole kdecore kdeui ${INSTALL_TARGETS_DEFAULT_ARGUMENTS})
>>
>> Later on this could be extended once we require (or can optionally use, not
>> sure about that) CMake 2.6 which supports library frameworks on OSX, they
>> need even more locations.
>
> I think I prefer this option. It works with cmake 2.4.5 and we will be able
> to
> extend it later on. It kind of slightly breaks source compatibility on
> Windows, but since we don't have an official release there this is no
> problem.
> A patch for this is attached. If we agree on this, I'd prefer if one of the
> windows developers could apply it, after he made sure installing works
> correctly on his system.
>
> Comments ?
>
No :)
Just let us know when you checked it in as it breaks windows install.
Thx,
Christian
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [Patch] introduce new cmake var KDE4_LIB_DESTINATION
On Saturday 16 February 2008, Christian Ehrlicher wrote: > Alexander Neundorf schrieb: ... > > Comments ? > > No :) > > Just let us know when you checked it in as it breaks windows install. Can you do this and at the same time fix at least kdelibs ? Alex ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: [Patch] introduce new cmake var KDE4_LIB_DESTINATION
Alexander Neundorf schrieb: > On Saturday 16 February 2008, Christian Ehrlicher wrote: >> Alexander Neundorf schrieb: > ... >>> Comments ? >> No :) >> >> Just let us know when you checked it in as it breaks windows install. > > Can you do this and at the same time fix at least kdelibs ? > Ok, I'll add it during the next week. Christian ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
