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