Re: [RFC] Add expat to the GDB sources

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Mon, 24 Jul 2006 11:24:38 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> On Mon, Jul 24, 2006 at 01:18:31AM +0200, Mark Kettenis wrote:
> >> Date: Sun, 23 Jul 2006 18:40:32 -0400
> >> From: Christopher Faylor <cgf-gdb-patches@sourceware.org>
> >> 
> >> On Tue, Jul 18, 2006 at 09:40:48AM -0400, Daniel Jacobowitz wrote:
> >> >At the beginning of the year, I proposed adding an XML parsing library to
> >> >GDB.
> >> 
> >> ...and, FWIW, there's already an expat directory at the top-level of src
> >> which exists entirely as a branch (which you <Daniel> announced).
> >> 
> >> Just as a meta-issue, I have to wonder at the precedent of one of the
> >> projects which shares 'src' adding directories to the top-level.
> >> 
> >> I just built gdb on linux and I see that it pulls in ncurses but there
> >> is no ncurses directory in src.  Why can't we just say that "building
> >> gdb requires a native expat library >= some version" like we do with
> >> ncurses?  Any other project which uses expat would just add detection of
> >> the expat library to the configure phase.
> >
> >Any UNIX-like system shipped within the last decade comes with a
> >decent curses implementation, wo we consider it to be a part of the
> >operating system.  Apart from Linux there are probably no systems that
> >ship with expat.  And even on most Linux systems expat won't be usable
> >because the bloody expat "development" package isn't installed.
> >
> >Depending on an external expat package comes with the additional
> >maintenance cost of testing the detection code and handling additional
> >bug reports from people who can't build gdb because of problems with
> >expat.
> >
> >> I've really always hated the habit of duplicating (and essentially forking)
> >> other project's source code in 'src' and putting expat there just seems
> >> like a step backwards to me.
> >
> >Well, I really detest that many software packages have so many
> >dependencies that I spent an hour hunting down the dependency chain
> >before I get actually to building the package I want.
> 
> I hate that too but that scenario is less of an inconvenience these days
> with tools like emerge, yum, or apt.

Unfortunately I'm on an rpm-based system without root access :(.

Adding external dependencies to gdb would really inconvenience me.  I
test regularly on systems where people have given me a "guest"
account.  Having to install dependencies first really sucks.  And
since I'd have to do that in a non-default location, it means I'm not
really testing the setup that people are actually going to use on
those systems.

> OTOH, having built hundreds of different packages for linux, one thing
> that really drives me up the wall is when a package includes their own
> version of a well-known library.  Did they include it because there is
> an incompatibility with the shipping version?  Were they too lazy to add
> a configure test?  Did they modify the library?  Will it only work with
> the 0.9 version of the library?  Is it going to install the library?

Hey, nobody forced you to look at what you're installing in that much
detailt ;-)

Mark