Adding noclosure to KDE_OPTIONS

[Lubos Lunak]

On Sunday 19 of September 2004 22:25, Adriaan de Groot wrote:
> In all of KDE CVS, as far as I can tell, there are exactly _two_
> noinst_LIBRARIES which are Qt based (most noinsts are pure C convenience
> thingies). Once is kdepim/libemailfunctions, the other is somewhere in
> kdenetwork/kopete.

 No no no, you're mistaken. If there are only two noinst Qt-based libraries in 
KDECVS, then they're definitely both kdebase/khotkeys - I can see them 
there :).

> The thing with noinsts is that they don't get the usual 
> $(LIB_QT) added, and when you throw --enable-closure into the mix, they
> don't link at all anymore, since the (now required) references to libqt-mt
> and whaterver else aren't made.
>
> In kdepim/, I added $(LIB_QT) and $(LIB_KDECORE) to _LIBADD, which makes it
> link again. In kopete, I can't tell so quickly what needs to be added, the
> library structure seems to be a bit of a mess. It suggests to me that we
> need something similar to KDE_OPTIONS=nofinal -- a KDE_OPTIONS=noclosure,
> that prevents closure in those places where we need it (alternatively, not
> doing closure on C++-based libs might work as well, but sounds trickier).
>
> The attached patch adds this, and seems to work for libemailfunctions at
> least. OK?

 That doesn't make any sense to me. Why don't you simply fix the libraries? 
Besides, the original purpose of closures is something about collecting 
missing symbols at link time (templates stuff and so, not necessary with gcc, 
so I'm not sure if it actually does something), the fact that it checks for 
undefined symbols is just a side effect.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/