Fwd: KDE/kdebase/libkonq

[David Faure]

On Wednesday 01 March 2006 15:08, you wrote:
> Am Mittwoch, 1. März 2006 14:24 schrieb David Faure:
> > On Wednesday 01 March 2006 13:48, Thiago Macieira wrote:
> > > David Faure wrote:
> > > >We really need some ${LIB_KPARTS} alias which expands to
> > > >  kparts kde3support kdeui kio DCOP ${QT_QTGUI_LIBRARY}
> > > > ${QT_QT3SUPPORT_LIBRARY} ${QT_QTXML_LIBRARY} kdefx ${ZLIB_LIBRARY}
> > > > ${X11_LIBRARIES} Is that possible?
> > > >
> > > >This is just too much details to be right.
> > >
> > > Being pedantic:
> > > ${LIB_KPARTS} should expand to "kparts" only. The build system has to
> > > figure out kparts' dependencies on its own.
> >
> > I thought that this couldn't be done since Windows dlls, or static libs, or
> > both, don't record their dependencies, iirc.
> >
> > So my suggestion achieves the same goal, more easily. To the "user" (i.e.
> > the one who writes a CMakeFiles.txt for his lib or app) the effect is the
> > same anyway: specifying LIB_KPARTS should be enough (we agree on that at
> > least ;)
> 
> That is for sure very ugly. Then we need to figure this out using something 
> like pkgconfig at least - that should be available too. At least for this 
> very purpose.

Doesn't sound like portable solution to me.

I mean if that's the only way to know which kde libs kparts depends upon, then it won't work
on windows and we need another solution there anyway, so why not do it always the same:

When writing ${LIB_KPARTS} we -know- that this means
   kparts+kio+kdeui+kdecore+kdefx+dcop+qtxml+qtgui+qtcore,
and this can be changed in one cmake module easily (with nested aliases of course, so in fact
it should be ${LIB_KPARTS}=kparts+${LIB_KIO} ).

If you mean the stuff under Qt, like X and zlib then ok, pkgconfig would be ok for those.

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