Re: [RFC] Add expat to the GDB sources

[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.

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?

Then there's the question of being polite to the expat maintainers.  Do
they want to field questions from gdb users who wonder why the version
that we have in 'src' doesn't work right?  I would imagine not.

I'm almost pathologically adverse to repeated stupid user questions but
I think in this case, I'd rather take the hit of documenting the best
way of grabbing expat for a particular OS and pointing people there
rather than adding YA duplication to 'src'.  I would really like to see
a day when 'src' will no longer include 'tcl', or 'readline', or
'expat'.

cgf