renaming kde-config to kde4-config

[Ralf Habacker]

Thiago Macieira schrieb:
> David Faure wrote:
>   
>> 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.
>>     
>
> That's because we had decided that the kdeinit modules have the same name 
> as their binaries and, therefore, there can be no two binaries/modules 
> with the same name in the same prefix.
>
> If we move the binaries out of $prefix/bin, we need to move the modules 
> too or invent a new naming scheme.
>
> I, for one, don't want to see a different naming scheme for libexec and 
> for bin binaries, since that will add complexity.
>
>   
>> 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? On Windows, you can simply put the .DLL in the same bindir as 
> the executable.
>
>   
>> 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 (all 
> except AIX and Windows)
>
> QLibrary library("kdeinit_kbuildsycoca", 4)
> will find the files:
> 	kdelibs_kbuildsycoca.dll (Windows)
> 	kdelibs_kbuildsycoca.sl.4 (HP-UX 32-bit)
> 	kdelibs_kbuildsycoca.so.4 (HP-UX 64-bit)
> 	kdelibs_kbuildsycoca.a (AIX)
> 	kdelibs_kbuildsycoca.4.bundle (MacOS X)
> 	kdelibs_kbuildsycoca.4.dylib (MacOS X)
> 	kdelibs_kbuildsycoca.so.4 (all others and MacOS X)
> 	libkdelibs_kbuildsycoca.sl.4 (HP-UX 32-bit)
> 	libkdelibs_kbuildsycoca.so.4 (HP-UX 64-bit)
> 	libkdelibs_kbuildsycoca.a (AIX)
> 	libkdelibs_kbuildsycoca.4.bundle (MacOS X)
> 	libkdelibs_kbuildsycoca.4.dylib (MacOS X)
> 	libkdelibs_kbuildsycoca.so.4 (all others and MacOS X)
>
> 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)
>
>   
This will only work until an update with an abi incompatible change will 
be there.
On window QT uses already the '4' in the dll name for example 
QtCore4.dll. Similar support for KDE  would only require to build dll 
names with the major dll version number [1] because windows uses import 
libraries, which are named according to the library base name. The real 
dll name is placed into this import libraries and is not public visible. 
Any relinked executable/dll using those import libraries will 
automatically use the related dll name, it may have a specific 
prefix/suffix or not in the name.


[1] this may differ from official release naming and has to be updated 
by any incompatible application binary interface change. If I remember 
right, this is already used by recent kde development.

Ralf