Re: Getting rid of the LIB_INSTALL_DIR hack on windows
On 13.01.08 01:25:18, Andreas Pakulat wrote:
> On 12.01.08 17:42:28, Christian Ehrlicher wrote:
> > Hi,
> >
> > I know we discussed this already, but I'm very unhappy with the current
> > solution.
> > The problem is (for all who don't remember) that we want to install the
> > shared libs into /bin on windows. When we install the shared libs into
> > /lib, we've to add an entry to the PATH env variable. Also it's not the
> > normal way to install shared libs in another location than the
> > executable - it would just confuse the user.
> >
> > Because of this a hack for LIB_INSTALL_DIR was added:
> > set(LIB_INSTALL_DIR "lib${LIB_SUFFIX}"
> > RUNTIME DESTINATION "bin"
> > LIBRARY DESTINATION "lib${LIB_SUFFIX}"
> > ARCHIVE DESTINATION "lib${LIB_SUFFIX}" )
> >
> > This works fine until someone uses LIB_INSTALL_DIR in another context -
> > e.g. to install additional files, see kdepimlibs/gpgme++:
> >
> > install(
> > FILES
> > ${CMAKE_CURRENT_BINARY_DIR}/GpgmeppConfig.cmake
> > ${CMAKE_CURRENT_BINARY_DIR}/GpgmeppLibraryDepends.cmake
> > DESTINATION
> > ${LIB_INSTALL_DIR}/gpgmepp )
>
> Thats broken in gpgme++ actually. Those .cmake files belong to
> /share/cmake/modules just the same as other .cmake module files.
Uhm, sorry, please just ignore that message. I missed the "Config" in
that name. Though I wonder a bit why it is needed, after all kdelibs'
FindKDE4Internal.cmake already helps cmake quite a lot to find other
FindFoo.cmake files, by adding all KDEDIRS entries to the list of dirs
to be searched...
Andreas
--
Your lucky number has been disconnected.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Getting rid of the LIB_INSTALL_DIR hack on windows
On 12.01.08 17:42:28, Christian Ehrlicher wrote:
> Hi,
>
> I know we discussed this already, but I'm very unhappy with the current
> solution.
> The problem is (for all who don't remember) that we want to install the
> shared libs into /bin on windows. When we install the shared libs into
> /lib, we've to add an entry to the PATH env variable. Also it's not the
> normal way to install shared libs in another location than the
> executable - it would just confuse the user.
>
> Because of this a hack for LIB_INSTALL_DIR was added:
> set(LIB_INSTALL_DIR "lib${LIB_SUFFIX}"
> RUNTIME DESTINATION "bin"
> LIBRARY DESTINATION "lib${LIB_SUFFIX}"
> ARCHIVE DESTINATION "lib${LIB_SUFFIX}" )
>
> This works fine until someone uses LIB_INSTALL_DIR in another context -
> e.g. to install additional files, see kdepimlibs/gpgme++:
>
> install(
> FILES
> ${CMAKE_CURRENT_BINARY_DIR}/GpgmeppConfig.cmake
> ${CMAKE_CURRENT_BINARY_DIR}/GpgmeppLibraryDepends.cmake
> DESTINATION
> ${LIB_INSTALL_DIR}/gpgmepp )
Thats broken in gpgme++ actually. Those .cmake files belong to
/share/cmake/modules just the same as other .cmake module files.
Andreas
--
Living your life is a task so difficult, it has never been attempted before.
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Getting rid of the LIB_INSTALL_DIR hack on windows
Michael Pyne schrieb:
> On Saturday 12 January 2008, Christian Ehrlicher wrote:
>
>> Hi,
>>
>> I know we discussed this already, but I'm very unhappy with the current
>> solution.
>> The problem is (for all who don't remember) that we want to install the
>> shared libs into /bin on windows. When we install the shared libs into
>> /lib, we've to add an entry to the PATH env variable. Also it's not the
>> normal way to install shared libs in another location than the
>> executable - it would just confuse the user.
>>
>> Because of this a hack for LIB_INSTALL_DIR was added:
>> set(LIB_INSTALL_DIR "lib${LIB_SUFFIX}"
>> RUNTIME DESTINATION "bin"
>> LIBRARY DESTINATION "lib${LIB_SUFFIX}"
>> ARCHIVE DESTINATION "lib${LIB_SUFFIX}" )
>>
>> This works fine until someone uses LIB_INSTALL_DIR in another context -
>> e.g. to install additional files, see kdepimlibs/gpgme++:
>>
>>
>
>
>> Therefore I want to change all CMakeLists.txt from
>>
>> install(TARGETS foo DESTINATION ${LIB_INSTALL_DIR} )
>>
>> to
>>
>> install(TARGETS foo RUNTIME DESTINATION ${BIN_IINSTALL_DIR}
>> LIBRARY DESTINATION ${LIB_INSTALL_DIR}
>> ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
>> )
>>
>> An additional macro install_kde_library() would work as well.
>>
>
> I like the macro idea a beeellion times better.
me too.
> Especially since it documents
> the intent better (i.e. use this for libraries, not for anything else).
>
> Then we could switch libraries to use install_kde4_library() and leave the
> rest alone.
>
Because there are already kde4_... macros, i suggest to use
kde4_install_library() as macro name
Ralf
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Getting rid of the LIB_INSTALL_DIR hack on windows
On Saturday 12 January 2008, Christian Ehrlicher wrote:
> Hi,
>
> I know we discussed this already, but I'm very unhappy with the current
> solution.
> The problem is (for all who don't remember) that we want to install the
> shared libs into /bin on windows. When we install the shared libs into
> /lib, we've to add an entry to the PATH env variable. Also it's not the
> normal way to install shared libs in another location than the
> executable - it would just confuse the user.
>
> Because of this a hack for LIB_INSTALL_DIR was added:
> set(LIB_INSTALL_DIR "lib${LIB_SUFFIX}"
> RUNTIME DESTINATION "bin"
> LIBRARY DESTINATION "lib${LIB_SUFFIX}"
> ARCHIVE DESTINATION "lib${LIB_SUFFIX}" )
>
> This works fine until someone uses LIB_INSTALL_DIR in another context -
> e.g. to install additional files, see kdepimlibs/gpgme++:
>
> Therefore I want to change all CMakeLists.txt from
>
> install(TARGETS foo DESTINATION ${LIB_INSTALL_DIR} )
>
> to
>
> install(TARGETS foo RUNTIME DESTINATION ${BIN_IINSTALL_DIR}
> LIBRARY DESTINATION ${LIB_INSTALL_DIR}
> ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
> )
>
> An additional macro install_kde_library() would work as well.
I like the macro idea a beeellion times better. Especially since it documents
the intent better (i.e. use this for libraries, not for anything else).
Then we could switch libraries to use install_kde4_library() and leave the
rest alone.
> Any objections?
> Christian
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
Getting rid of the LIB_INSTALL_DIR hack on windows
Hi,
I know we discussed this already, but I'm very unhappy with the current
solution.
The problem is (for all who don't remember) that we want to install the
shared libs into /bin on windows. When we install the shared libs into
/lib, we've to add an entry to the PATH env variable. Also it's not the
normal way to install shared libs in another location than the
executable - it would just confuse the user.
Because of this a hack for LIB_INSTALL_DIR was added:
set(LIB_INSTALL_DIR "lib${LIB_SUFFIX}"
RUNTIME DESTINATION "bin"
LIBRARY DESTINATION "lib${LIB_SUFFIX}"
ARCHIVE DESTINATION "lib${LIB_SUFFIX}" )
This works fine until someone uses LIB_INSTALL_DIR in another context -
e.g. to install additional files, see kdepimlibs/gpgme++:
install(
FILES
${CMAKE_CURRENT_BINARY_DIR}/GpgmeppConfig.cmake
${CMAKE_CURRENT_BINARY_DIR}/GpgmeppLibraryDepends.cmake
DESTINATION
${LIB_INSTALL_DIR}/gpgmepp )
Therefore I want to change all CMakeLists.txt from
install(TARGETS foo DESTINATION ${LIB_INSTALL_DIR} )
to
install(TARGETS foo RUNTIME DESTINATION ${BIN_IINSTALL_DIR}
LIBRARY DESTINATION ${LIB_INSTALL_DIR}
ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
)
An additional macro install_kde_library() would work as well.
I don't see a problem to add those three lines as it does not affect
linux/unix and when someone forgets to add them it doesn't hurt either -
we'll notice that something is wrong when we try to start an app on windows.
Leaving the macro as it is now just gives us weird cmake errors and
we've to find a hack to work around the usage of LIB_INSTALL_DIR in the
concerning cmake scripts.
Any objections?
Christian
signature.asc
Description: OpenPGP digital signature
___
Kde-buildsystem mailing list
Kde-buildsystem@kde.org
https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Auto-generated XML interfaces and dependencies
Hello, On Saturday 29 December 2007, Alexander Neundorf wrote: > I guess then one way would be to add a helper target > add_custom_target(CREATE_DBUS_STUFF) > which creates all the dbus xml interfaces, and have all the targets which > need these interfaces depend on this helper target. > > OTOH, if other targets need some part of what is built when kmail is being > built, then it doesn't seem to be that wrong to make them depend on kmail > (or the helper target). That sounds like a good idea. I don't know enough about CMake to do this myself though, can anyone help? I tried the following in the KMail CMake file: >add_custom_target( kmail_xml, > COMMAND qt4_generate_dbus_interface( kmkernel.h > org.kde.kmail.kmail.xml OPTIONS -a ) > COMMAND qt4_generate_dbus_interface( kmcomposewin.h > org.kde.kmail.mailcomposer.xml OPTIONS -a ) >) But that seems to be invalid syntax. What is the right way to do this? Afterwards, I simply do the following then, right? >add_dependencies(kontact_kmailplugin kmail_xml) What I find strange is that we currently have >add_dependencies(kontact_kmailplugin kmail) in there, which means that the Kontact KMail plugin depends on KMail. This however does not seem to work, there are still errors like > make[3]: *** No rule to make target `kmail/org.kde.kmail.kmail.xml', > needed by `kontact/plugins/kmail/kmailinterface.cpp'. Stop. > make[2]: *** [kontact/plugins/kmail/CMakeFiles/kcm_kmailsummary.dir/all] > Error 2 What are we doing wrong there? The CMake files are in kdepim/kmail/CMakeLists.txt and in kdepim/kontact/plugins/kmail/CMakeLists.txt. Can anybody have a look at that please? Thanks, Thomas P.S. Sorry for the late response ___ Kde-buildsystem mailing list Kde-buildsystem@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
