glib dependancy in KDE3.x
neil at qualityassistant.com
Thu Mar 6 12:14:25 GMT 2003
-----BEGIN PGP SIGNED MESSAGE-----
On Thursday March 06, 2003 02:02, Stefan Westerfeld wrote:
> On Thu, Mar 06, 2003 at 01:32:57AM -0800, Neil Stevens wrote:
> > On Thursday March 06, 2003 01:03, Stefan Westerfeld wrote:
> > > Thus, I am considering removing the glib compatibility code from
> > > aRts, and depending on the real thing in the future. The question
> > > is: are there any objections and/or comments against doing this
> > > within the KDE3.x cycle (i.e. for KDE3.2)?
> > The glib stuff is entirely internal to artsd right?
> I do not plan to expose glib at the API level, if you mean that. So the
> step will not introduce any g_xxx_yyy function in code that uses aRts.
> In other words: I plan to maintain binary compatibility, which I have
> committed myself to during the KDE3 development cycle.
No, I meant whether this would force all libartskde apps to link to the
> However, a dependancy is a dependancy, and as such libmcop, libartsflow,
> ... will gain an additional dependancy on glib-2.0.
... and I guess you mean to.
Could you maintain the version you want in kdesupport? That'd make it
painless, and for a bunch of people it would mean the change would require
no additional things to install. That's where all the other GNOME libs
are being kept anyway, protecting the average developer from any hassles.
Neil Stevens - neil at qualityassistant.com
"Among the many misdeeds of the British rule in India, history will
look upon the act depriving a whole nation of arms as the blackest."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-core-devel