Re: [Patch] introduce new cmake var KDE4_LIB_DESTINATION
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.
>
> On Linux it's simply LIB_INSTALL_PREFIX:
> _set_fancy(KDE4_LIB_DESTINATION ${LIB_INSTALL_DIR})
I think the variable shouldn't have the KDE4_ prefix, since this is used for
the variables which are "imported" from the installed kdelibs (i.e. which
show the install location of the installed kdelibs), which can be different
from the install locations of the current project.
So we need another name.
> and on windows it's
> set(KDE4_LIB_DESTINATION RUNTIME DESTINATION "bin"
> LIBRARY DESTINATION "lib${LIB_SUFFIX}"
> ARCHIVE DESTINATION "lib${LIB_SUFFIX}" )
>
>
> The reason why we need a special var instead using LIB_INSTALL_DIR is
> that we currently can't use LIB_INSTALL_DIR somewhere outside
> install(TARGET ...) but sometimes we simply need it :)
Is this the only reason ?
Maybe we could also do it the other way, keep LIB_INSTALL_DIR as it is and add
LIB_INSTALL_PREFIX (or something like that), which would contain really only
that one directory on all platforms.
This would be less work I think, because all the install(TARGETS ... ) (except
the problematic ones) could stay unchanged.
I'm still really undecided.
You know, if we keep using the basically regular syntax using the
LIB_INSTALL_DIR hack (on windows), somebody who knows cmake will just see
what it does (except for windows). If he doesn't already know cmake, he can
learn from that for his own projects without having to use the KDE4 cmake
macros. This is a significant feature, which I really value.
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.
Next option:
Once we _require_ CMake 2.6.x (so maybe for KDE 4.2), we could use the
framework feature of cmake for all libraries in KDE, and I could add the
feature to cmake so that the install locations could be initialized from
target properties of that target. Setting these properties could be done in
KDE4_ADD_EXECUTABLE/LIBRARY/...()
Then the install command would look something like:
install(TARGETS konsole kdecore kdeui USE_TARGET_PROPERTIES)
We can also keep in mind that KDE 4.0 hasn't been released on Windows, so we
don't have to keep compatibility there yet. I.e. if somebody today relies on
the fact that LIB_INSTALL_DIR contains all three locations on Windows, we
still can break that. We just have to ensure that
install(TARGETS kdecore DESTINATION ${LIB_INSTALL_DIR})
stays working on UNIX (OSX excluded, also not officially released yet).
Opinions ?
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
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: [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
Re: [Patch] introduce new cmake var KDE4_LIB_DESTINATION
On Monday 18 February 2008, Christian Ehrlicher wrote: > 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, done for kdelibs, kdepimlibs, kdebase-runtime, kdebase-apps, kdeedu > and kdebase. Cool. Maybe it would have been even better if we (you) would have first committed it to kdelibs and one week later to the other modules, now everybody has to update kdelibs. Actually only FindKDE4Internal.cmake. I guess I should send a notification email. > I just noticed that we maybe have a problem in kdepimlibs because it > should also be compileable with kde4.0 - but think this can be fixed > somehow. Do we have a kde version check ? I guess I should add something RSN ... 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, done for kdelibs, kdepimlibs, kdebase-runtime, kdebase-apps, kdeedu and kdebase. I just noticed that we maybe have a problem in kdepimlibs because it should also be compileable with kde4.0 - but think this can be fixed somehow. Do we have a kde version check ? 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
Alexander Neundorf schrieb: > On Monday 18 February 2008, Christian Ehrlicher wrote: >> 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, done for kdelibs, kdepimlibs, kdebase-runtime, kdebase-apps, kdeedu >> and kdebase. > > Cool. > Maybe it would have been even better if we (you) would have first committed > it > to kdelibs and one week later to the other modules, now everybody has to > update kdelibs. > Actually only FindKDE4Internal.cmake. > > I guess I should send a notification email. *grml* blame me for the crap :( I way just so happy that it works now and ca be removed from my list. Sorry, Christian ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
