Getting rid of the LIB_INSTALL_DIR hack on windows
Andreas Pakulat
apaku at gmx.de
Sun Jan 13 01:52:25 CET 2008
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
> <prefix>/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.
More information about the Kde-buildsystem
mailing list