is new lib dependency possible for 3.5.2?

[Matt Rogers]

On Monday 30 January 2006 12:05, Leo Savernik wrote:
> Am Sonntag, 29. Januar 2006 22:48 schrieb Michael Pyne:
> > "You depend on our library and we'll depend on 2 of yours."
> >
> > It was almost be a nice argument except that, for whatever reason those
> > Kuh-raaaazay GNOME guys have decided that they want their base libs coded
> > in C.  I'm sure you already know how difficult it can be to use C++ code
> > with no C bindings from C.
>
> No excuse. Those can be autogenerated.
>
> > On the other hand, using C code from C++ is often merely annoying, and
> > can sometimes even be just a slight chore with a few decent C++ wrappers
> > of C classes.
> >
> > In other words, it is easier for us to depend on a C library than it is
> > for them to depend on a C++ library.
>
> From a compilers point of view, yes. But we pay the full price. If we
> really needed the lib, ok. But there's no functionality in glib not already
> covered by the libstdc++/QtCore combo.
>
> > And besides, QtCore does so much just by itself that we'd really have to
> > depend on about half of GNOME's libs to make it a tit-for-tat arrangement
> > if they were to depend on QtCore.
>
> That's an even stronger reason to not depend on any library whose
> functionality is already provided from "within".
>
> mfg
> 	Leo

So you're suggesting that time be wasted to reimplement something that already 
has an equivalent, but due to it's dependance on glib, shouldn't be used 
because other libraries we use already provide the same thing?

No offense, but that sounds very much like NIH syndrome to me.
-- 
Matt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060130/ecb85467/attachment.sig>