renaming kde-config to kde4-config

[David Faure]

On Sunday 24 December 2006 19:58, Thiago Macieira wrote:
> If we move the binaries out of $prefix/bin, we need to move the modules 
> too or invent a new naming scheme.

Moving the modules means another directory that must be in the ld.so search path
(e.g. LD_LIBRARY_PATH) - doesn't really look like an option.
So I guess the new naming scheme is the best option.

> >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).
> 
> Do you know of any system that doesn't properly support RPATH or an equivalent?

Actually, I dug some more now, and this isn't even the issue here. 
The issue is that kde3 doesn't have all RPATHs set properly, so it just doesn't work.

From a kde4 environment (including LD_LIBRARY_PATH pointing to /d/kde/inst/kde4/lib/), I do:

ldd /usr/bin/klauncher | grep kdeinit
        libkdeinit_klauncher.so => /d/kde/inst/kde4/lib/libkdeinit_klauncher.so (0xb7fa4000)
=> Ouch that should be /usr/lib/libkdeinit_klauncher.so.
But the RPATH isn't set:
objdump -p /usr/bin/klauncher | grep PATH
shows no result.

Too late to fix kde3 now, imho. And anyway this only helps with different prefixes (my setup)
not with the same prefix (the setup that debian/ubuntu is going to use if we make it possible).

> >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).
> 
> Just add a .4 at the end for all modules. QLibrary is capable of finding 
> the proper version of a library/module in almost all platforms.

Sounds good. Alex, can you check if cmake can do that?
kde4_add_kdeinit_executable(kbuildsycoca NOGUI ${kbuildsycoca_KDEINIT_SRCS})
should create a libkdeinit_kbuildsycoca.so.4 instead of a libkdeinit_kbuildsycoca.so
This isn't really like the prefix/suffix stuff that you suggested in another mail, I'm afraid.

> I guess we don't have to bribe anyone at Trolltech too much to make it 
> find kdelibs_kbuildsycoca4.dll too :-) (but there we can simply put the 
> DLL in the same dir as the executable)
Windows doesn't use the kdeinit "fork+dlopen" trick anyway, so no problem there.

On Saturday 30 December 2006 18:38, Alexander Neundorf wrote:
> > 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.
> 
> Which modules are these ? 
I guess you mean which tools? kdelibs installs the following tools with a kdeinit module:
cupsdconf, kaddprinterwizard, kbuildsycoca, kcmshell, kconf_update, kded, kio_http_cache_cleaner,
kio_uiserver, klauncher, knotify.

> I guess this would affect the KDE startup speed ?
Alledgedly not that much, but I'm not the expert in that area.

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