KDE/kdelibs

Benjamin Reed rangerrick at befunk.com
Wed Nov 9 20:08:50 CET 2005


Ralf Habacker wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>  
> 
> 
> Benjamin Reed schrieb:
> 
>> SVN commit 479232 by reed:
>>
>> this adds a lot of chaff to the lib lines, but until we have proper
>> .dep or .la parsing to track dependent libraries, this is the only
>> way to link on systems that care about undefined indirect symbols
>> from other libraries
>>
> in svn initial .dep file support is integrated.
> If someone can give me a hint how to get the dependency from the
> indirect used libraries I can write it into the related dep file and
> add them as dependencies.

We basically need to follow the dependency chain of each library.  It 
will require reading each .dep file and figuring out what it's 
dependencies are.

We'll need to know the path to the dep files to be able to do that, and 
I guess the actual build/ location of the libraries that dep file 
represents (basically, the stuff that's encoded into .la files)

for example...

DCOP.dep contains:
uselib='QT QTCORE QT3SUPPORT KDE4'

Then, when linking libkdecore, we'll link it against DCOP.dep, which 
then knows that for -lDCOP to link requires uselib='QT QTCORE QT3SUPPORT 
KDE4'.

so kdecore.dep contains:
uselib='QT QTCORE QT3SUPPORT KDE4 QTGUI KDE4 LIBIDN DL'

which is the union of dcop's (QT QTCORE QT3SUPPORT KDE4) and kdelibs' 
(QT QTCORE QTGUI QT3SUPPORT KDE4 LIBIDN DL)

This may not be necessary for platforms that allow you to link 
libkdecore and not need to add everything libkdecore linked against, but 
for Mac OS X (and probably others) it does matter.

Anything that links against a previous .dep file needs uselib and libs 
to be a superset of it's own options, and any dependent library's options.



More information about the Kde-buildsystem mailing list