Re: [RFC] Add expat to the GDB sources

Mark Kettenis
2006-07-24T22:08:20Z

> 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