library dependency implementation

Ralf Habacker ralf.habacker at freenet.de
Tue Oct 25 19:17:28 CEST 2005


Am Dienstag, 25. Oktober 2005 18:12 schrieb Jarosław Staniek:
> Ralf Habacker said the following, On 2005-10-25 18:01:
> > Hi all,
> >
> > I like to know some suggestions for the bksys implementation relating to
> > the subject. The background:
> >
> > genobj classes provides the lib and libpaths attribute for selecting
> > required external and internal libraries.  There are platform depending
> > forms like
> >
> > obj.libs = '../kdecore/libkdecore.a'
>
> BTW, First issue, there's one more platform-dependent thing hardcoded:
> 'lib' prefix. Easily removable.

but this is the default on linux, mingw and may be other os/compiler. 

The challenge is 

1. to find a way to specify libraries platform independent  for example 
obj.target='kdecore' and not obj.target='libkdecore' -> not a real problem 

2. to reference libraries platform independent. -> the real challenge 

This is the reason, why I introduced the libpaths/libs form without any 
prefix/suffix but there are issues in the implementation I have reported  

> > and platform independent forms like
> >
> > obj.libs = '../kdecore/libkdecore.la'
> >
> > (because la files are now also available for static libs)
> >
> > another form is using libs and libpaths
> >
> >
> > obj.libpaths = 'path another_path'
> > obj.libs = 'lib1 lib2'
> >
> > All this attributes are used for the link line and the linker checks all
> > obj.libpaths for libraries specified in obj.libs.
> >
> > For several reasons it is required for bksys to know the exact path of a
> > given library and the above mentioned form requires to scan all given
> > pathes for shared and static libraries or la files to detect what to do
> > which this library.
> >
> > This relates to the whole-archive linker option, which is required to
> > include static libraries into a shared library using gcc/ld. To use this
> > option the absolute path of the static library is required and could be
> > retrieved from the relating la file.
>
> BTW, I guess you didn't mean cases like kde-ice, and kde3support? These are
> compiled in one go without static-libraries hack. What cases do you have in
> mind then?

I would like to move this topic somewhere in the future and to avoid this 
static libraries as much as possible, but I don't know if this support isn't 
required in some cases. 


REgards
 Ralf 



More information about the Kde-buildsystem mailing list