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

List:       kde-core-devel
Subject:    Re: libkio & libksycoca
From:       David Faure <david () mandrakesoft ! com>
Date:       2001-11-30 17:02:41
[Download RAW message or body]

On Friday 30 November 2001 14:45, Lubos Lunak wrote:
>  DCOP = DCOP
>  kdecore = kdecore
>  kdeui = kdeui
>  kdefx = kdefx
>  kio = kio+kdesu+kssl+ksycoca+kfile (the new name should be probably 
> different from libkio)

Sounds good to me. The name is hard to find indeed.... khighlevel ? ;)
keverythingelse ? kstuff ? Oh boy I have become as bad as tronical when
it comes to finding names ;-))
Well, kio is a well-known name (much more than e.g. ksycoca), so maybe
we could keep it, and if anyone asks, "it's named this way for historical
reasons ;)".

> Packing everything in one huge lib wouldn't be a thing kdelibs developers 
> would like I'm afraid (link time increases). 
That's right - and the noinst_ libs are always confusing, since make install
on them does nothing... (just like in khtml). But if we want to use stuff from
kfile in kio and the other way round, there's no other way.

>  Actually, there is one problem with putting the rest in libkio, the build 
> order. Now, it's built kdesu->kssl->kio->ksycoca->kio subdirs->kfile . The 
> new order should become something like 
> kdesu->kssl->kio+ksycoca->kfile->create new kio->kio subdirs (i.e. everything 
> that links against any of the libs). 
Right. So we have to move some stuff around, we can't go into kio and then to
kfile, for going back to kio again afterwards, for its subdirs. I guess those subdirs
could be moved to the toplevel, e.g. kioslave/ for the slaves (to mirror kdebase),
kded, kdesasl, klauncher, etc. That, or moving kfile into kio/. Might be easier actually.

> I'm also not sure about those variables 
> like LIB_KSYCOCA, LIB_KFILE. Any idea what to do with this without messing up 
> everything?
Simple IMHO: they should all be defined to -lkio (or whatever we name the resulting
lib). Reason: well-written Makefile.ams only use one of those variables, e.g.
blah_LDADD=$(LIB_KFILE). So it has to become the lib in question. The very
few redundancies that will happen, leading to e.g. -lkio -lkio -lkio, won't matter much.

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://perso.mandrakesoft.com/~david/ , http://www.konqueror.org/
KDE 3.0: Konquering the Desktops

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