[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: renaming kde-config to kde4-config
From:       David Faure <faure () kde ! org>
Date:       2006-12-24 17:44:33
Message-ID: 200612241844.34631.faure () kde ! org
[Download RAW message or body]

On Tuesday 27 June 2006 11:21, David Faure wrote:
> Actually my idea was: we could support installing kdelibs3 and kdelibs4 into the \
> same prefix, if we move most helper binaries to libexec/kde4.

I discovered a problem with that: the kdeinit module.
Even if I move kde4's kbuildsycoca to <kde4prefix>/lib/kde4/libexec, I end up with:
both /usr/bin/kbuildsycoca (from kde3) and <kde4prefix>/lib/kde4/libexec/kbuildsycoca \
linking to a "libkdeinit_kbuildsycoca.so" so even with different prefixes, the kde3 \
kbuildsycoca (called by a kde3 program) ends up running the kde4 code  from \
<kde4prefix>/lib/libkdeinit_kbuildsycoca.so since it's found first (due to \
LD_LIBRARY_PATH). (I guess we can't just rely on RPATH at this point, for full \
portability).

With the kdeinit-module naming scheme I can't just rename the kdeinit module, it has \
to be found as libkdeinit_appname, otherwise kdeinit won't be able to dlopen the \
module.

If I rename the binary and the kdeinit module to kbuildsycoca4, then moving it to \
libexec was a bit pointless, the binary might as well remain in bin. But I wanted to \
clean up bin from internal tools (ok kbuildsycoca isn't so internal, since we \
sometimes suggest to run it, but the problem will remain for other tools).

Another option is to start versioning the kdeinit modules - but making sure we don't \
install a .so symlink so that both can be installed in the same prefix.... Sounds \
difficult and unportable (dlls).

And finally, another option is to version inside the name itself, i.e. change the \
kdeinit naming scheme  so that kde4_add_kdeinit_executable( kbuildsycoca ...)
actually defines a kbuildsycoca binary linking to a libkdeinit_kbuildsycoca4.so - \
i.e. adding a '4' automatically. But then all our CMakeLists.txt code like 
 target_link_libraries(kdeinit_kbuildsycoca  [some libs] )
must be adjusted to
 target_link_libraries(kdeinit_kbuildsycoca4  [some libs] )
Unless this can benefit from some cmake magic where the target name differs from the \
actual library name on disk?

Maybe I should just drop the idea of making kbuildsycoca (and other such tools) \
kdeinit modules, since the gain is reportedly not that much nowadays.

David - undecided ;)

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).


[prev in list] [next in list] [prev in thread] [next in thread]