glib dependancy in KDE3.x

[Allan Sandfeld Jensen]

On Thursday 06 March 2003 16:25, Maksim Orlovich wrote:
> On Thu, 6 Mar 2003, Stefan Westerfeld wrote:
> >    Hi!
> >
> > I have found that not depending aRts on glib causes a lot of additional
> > maintainance overhead. Arts maintains its own threading abstraction, its
> > own mainloop, its own locks, its own glib mainloop integration, and a lot
> > of additional code duplication (~/src/arts/flow/gsl/gslglib.*).
>
> And what would happen if a bug in glib broke aRts?
> aRts is already a major maintenance hassle -- few people understand how it
> works, and the GSL code is just awful.  Tracing out the memory
> corruption in it (the gsl_foo_magic) for me was no fun -- particularly
> since following your instructions about it not being developed here, I've
> sent a patch fixing  the problem to you, only to have it ignored for
> months, and later fixed  indepedently by an another developer. The same of
> course can happen with any external dependency. Pretty much every outside
> lib we depend on has been a problem one time or another - libxml breaking
> docs build, glibc linker bugs killing designer, and of course Qt bugs
> breaking things do. The latter of course were always th eleast problem
> since practically any KDE developer can look at Qt code and fix most
> things.
>
> IMHO, unless we have absolute guarantees that any bugs would be handled by
> the maintainer promptly, which is rarely the case with any KDE apps,
> including aRts (seeing that bugs in aRts libs crashing Konqueror has been
> reported from early 2.x days all the way to 3.0.x), putting in that kind
> of code in there is a mistake.

Hopefully aRts will die soon when MAS obsoletes it.

`Allan