[RFC] Add expat to the GDB sources

[RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

At the beginning of the year, I proposed adding an XML parsing library to
GDB.  There was some discussion, and a few alternatives were proposed which
would accomplish the same goals, but neither substantially better nor
substantially worse.  Since then, we've fleshed out the project the XML
descriptions were originally intended for (targets which can inform the
debugger about their registers), and added another (memory maps, used to
control flash writing).

I chose expat as the C XML library to use in GDB.  It's a bit frustrating
(it's a stream-oriented binding, and I find DOM (tree-oriented) bindings
much more natural), but it's also useful and of a reasonable size.  The most
logical candidate for a DOM binding would have been libxml2, and the source
for that is excessive to include in GDB.

Here is a patch to add an expat directory to the src repository, gdb builds,
and gdb release tarballs.  Not shown is expat itself.

Any comments?  I will hold off on this patch for a little while, at least
until one of the expat clients is ready.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

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.  There was some discussion, and a few alternatives were proposed which
> would accomplish the same goals, but neither substantially better nor
> substantially worse.  Since then, we've fleshed out the project the XML
> descriptions were originally intended for (targets which can inform the
> debugger about their registers), and added another (memory maps, used to
> control flash writing).
> 
> I chose expat as the C XML library to use in GDB.  It's a bit frustrating
> (it's a stream-oriented binding, and I find DOM (tree-oriented) bindings
> much more natural), but it's also useful and of a reasonable size.  The most
> logical candidate for a DOM binding would have been libxml2, and the source
> for that is excessive to include in GDB.
> 
> Here is a patch to add an expat directory to the src repository, gdb builds,
> and gdb release tarballs.  Not shown is expat itself.
> 
> Any comments?  I will hold off on this patch for a little while, at least
> until one of the expat clients is ready.

D'oh!  With patch now.

-- 
Daniel Jacobowitz
CodeSourcery

2006-07-18  Daniel Jacobowitz  <dan@codesourcery.com>

	* expat: New directory.
	* Makefile.def (host_modules, dependencies): Add expat.
	* configure.in (host_libs): Add expat.
	* src-release (GDB_SUPPORT_DIRS): Add expat.
	* MAINTAINERS: Mention expat.
	* Makefile.in, configure: Regenerated.

2006-07-18  Daniel Jacobowitz  <dan@codesourcery.com>

	* Makefile.in (EXPAT, EXPAT_CFLAGS): New.
	(INTERNAL_CFLAGS_BASE, CLIBS, CDEPS, LINTFLAGS): Add expat.

Index: Makefile.def
===================================================================
RCS file: /cvs/src/src/Makefile.def,v
retrieving revision 1.69
diff -u -p -r1.69 Makefile.def
--- Makefile.def	7 Jun 2006 22:33:16 -0000	1.69
+++ Makefile.def	18 Jul 2006 13:13:51 -0000
@@ -47,6 +47,8 @@ host_modules= { module= dejagnu; };
 host_modules= { module= diff; };
 host_modules= { module= dosutils; no_check= true; };
 host_modules= { module= etc; };
+host_modules= { module= expat; no_install= true;
+                extra_configure_flags='--disable-shared'; };
 host_modules= { module= fastjar; no_check_cross= true; };
 host_modules= { module= fileutils; };
 host_modules= { module= findutils; };
@@ -304,6 +306,7 @@ dependencies = { module=all-gdb; on=all-
 dependencies = { module=all-gdb; on=all-build-bison; };
 dependencies = { module=all-gdb; on=all-build-byacc; };
 dependencies = { module=all-gdb; on=all-sim; };
+dependencies = { module=all-gdb; on=all-expat; };
 
 dependencies = { module=configure-libgui; on=configure-tcl; };
 dependencies = { module=configure-libgui; on=configure-tk; };
Index: configure.in
===================================================================
RCS file: /cvs/src/src/configure.in,v
retrieving revision 1.313
diff -u -p -r1.313 configure.in
--- configure.in	3 Jul 2006 11:22:03 -0000	1.313
+++ configure.in	18 Jul 2006 13:13:55 -0000
@@ -123,7 +123,7 @@ build_tools="build-texinfo build-byacc b
 
 # these libraries are used by various programs built for the host environment
 #
-host_libs="intl mmalloc libiberty opcodes bfd readline tcl tk itcl libgui zlib libcpp libdecnumber"
+host_libs="intl mmalloc libiberty opcodes bfd readline tcl tk itcl libgui zlib libcpp libdecnumber expat"
 
 # these tools are built for the host environment
 # Note, the powerpc-eabi build depends on sim occurring before gdb in order to
Index: src-release
===================================================================
RCS file: /cvs/src/src/src-release,v
retrieving revision 1.21
diff -u -p -r1.21 src-release
--- src-release	31 May 2006 15:14:34 -0000	1.21
+++ src-release	18 Jul 2006 13:13:55 -0000
@@ -270,7 +270,7 @@ gnats.tar.bz2: $(DIST_SUPPORT) $(GNATS_S
 		SUPPORT_FILES="$(GNATS_SUPPORT_DIRS)"
 
 .PHONY: gdb.tar.bz2
-GDB_SUPPORT_DIRS= bfd include libiberty opcodes readline sim intl
+GDB_SUPPORT_DIRS= bfd include libiberty opcodes readline sim intl expat
 gdb.tar.bz2: $(DIST_SUPPORT) $(GDB_SUPPORT_DIRS) gdb
 	$(MAKE) -f $(SELF) gdb-taz TOOL=gdb \
 		MD5PROG="$(MD5PROG)" \
Index: gdb/Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.827
diff -u -p -r1.827 Makefile.in
--- gdb/Makefile.in	12 Jul 2006 20:46:32 -0000	1.827
+++ gdb/Makefile.in	18 Jul 2006 13:13:56 -0000
@@ -128,6 +128,10 @@ READLINE = $(READLINE_DIR)/libreadline.a
 READLINE_SRC = $(srcdir)/$(READLINE_DIR)
 READLINE_CFLAGS = -I$(READLINE_SRC)/..
 
+# Where is the expat library?  Typically in ../expat.
+EXPAT = ../expat/.libs/libexpat.a
+EXPAT_CFLAGS = -I$(srcdir)/../expat/lib -I../expat
+
 WARN_CFLAGS = @WARN_CFLAGS@
 WERROR_CFLAGS = @WERROR_CFLAGS@
 GDB_WARN_CFLAGS = $(WARN_CFLAGS)
@@ -348,7 +352,7 @@ CXXFLAGS = -g -O
 INTERNAL_CFLAGS_BASE = \
 	$(CFLAGS) $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
 	$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) \
-	$(BFD_CFLAGS) $(INCLUDE_CFLAGS) \
+	$(BFD_CFLAGS) $(INCLUDE_CFLAGS) $(EXPAT_CFLAGS) \
 	$(INTL_CFLAGS) $(ENABLE_CFLAGS)
 INTERNAL_WARN_CFLAGS = $(INTERNAL_CFLAGS_BASE) $(GDB_WARN_CFLAGS)
 INTERNAL_CFLAGS = $(INTERNAL_WARN_CFLAGS) $(GDB_WERROR_CFLAGS)
@@ -376,10 +380,10 @@ INSTALLED_LIBS=-lbfd -lreadline -lopcode
 	-lintl -liberty
 CLIBS = $(SIM) $(READLINE) $(OPCODES) $(BFD) $(INTL) $(LIBIBERTY) \
 	$(XM_CLIBS) $(TM_CLIBS) $(NAT_CLIBS) $(GDBTKLIBS) @LIBS@ \
-	$(LIBICONV) \
+	$(LIBICONV) $(EXPAT) \
 	$(LIBIBERTY) $(WIN32LIBS)
 CDEPS = $(XM_CDEPS) $(TM_CDEPS) $(NAT_CDEPS) $(SIM) $(BFD) $(READLINE) \
-	$(OPCODES) $(INTL_DEPS) $(LIBIBERTY) $(CONFIG_DEPS)
+	$(OPCODES) $(INTL_DEPS) $(LIBIBERTY) $(CONFIG_DEPS) $(EXPAT)
 
 ADD_FILES = $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
 ADD_DEPS = $(XM_ADD_FILES) $(TM_ADD_FILES) $(NAT_ADD_FILES)
@@ -389,7 +393,7 @@ DIST=gdb
 LINT=/usr/5bin/lint
 LINTFLAGS= $(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) \
 	$(BFD_CFLAGS) $(INCLUDE_CFLAGS) \
-	$(INTL_CFLAGS)
+	$(INTL_CFLAGS) $(EXPAT_CFLAGS)
 
 RUNTEST = runtest
 RUNTESTFLAGS=
Index: MAINTAINERS
===================================================================
RCS file: /cvs/src/src/MAINTAINERS,v
retrieving revision 1.32
diff -u -p -r1.32 MAINTAINERS
--- MAINTAINERS	22 May 2006 15:30:13 -0000	1.32
+++ MAINTAINERS	18 Jul 2006 13:20:07 -0000
@@ -39,7 +39,7 @@ config.guess; config.sub; readline/suppo
 depcomp
         Send bug reports and patches to bug-automake@gnu.org.
 
-gdb/; readline/; sim/; GDB's part of include/
+gdb/; readline/; sim/; expat/; GDB's part of include/
 	GDB: http://www.gnu.org/software/gdb/
 	Patches to gdb-patches@sources.redhat.com.
 	See also gdb/MAINTAINERS and sim/MAINTAINERS.

Re: [RFC] Add expat to the GDB sources

[Joel Brobecker]

> > Any comments?  I will hold off on this patch for a little while, at least
> > until one of the expat clients is ready.
> 
> D'oh!  With patch now.

My only concern is with portability. I would assume that a project like
this one should easily be portable, but I can't find confirmation of
this on their web site. Is the list of know platforms where this builds
published somewhere?

-- 
Joel

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Thu, Jul 20, 2006 at 05:34:55PM -0700, Joel Brobecker wrote:
> > > Any comments?  I will hold off on this patch for a little while, at least
> > > until one of the expat clients is ready.
> > 
> > D'oh!  With patch now.
> 
> My only concern is with portability. I would assume that a project like
> this one should easily be portable, but I can't find confirmation of
> this on their web site. Is the list of know platforms where this builds
> published somewhere?

Not that I know of.  It did build out of the box on Cygwin and mingw32,
which is my usual benchmark for such things.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Joel Brobecker]

> Not that I know of.  It did build out of the box on Cygwin and mingw32,
> which is my usual benchmark for such things.

OK - I'm not too concerned, then. I can always deal with the exotic
platforms later. In fact, I should probably be more concerned about
getting rid of the warnings-becoming-errors than this...

Thanks Daniel,
-- 
Joel

Re: [RFC] Add expat to the GDB sources

[Mark Kettenis]

> Date: Tue, 18 Jul 2006 09:57:18 -0400
> From: Daniel Jacobowitz <drow@false.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.  There was some discussion, and a few alternatives were proposed which
> > would accomplish the same goals, but neither substantially better nor
> > substantially worse.  Since then, we've fleshed out the project the XML
> > descriptions were originally intended for (targets which can inform the
> > debugger about their registers), and added another (memory maps, used to
> > control flash writing).
> > 
> > I chose expat as the C XML library to use in GDB.  It's a bit frustrating
> > (it's a stream-oriented binding, and I find DOM (tree-oriented) bindings
> > much more natural), but it's also useful and of a reasonable size.  The most
> > logical candidate for a DOM binding would have been libxml2, and the source
> > for that is excessive to include in GDB.
> > 
> > Here is a patch to add an expat directory to the src repository, gdb builds,
> > and gdb release tarballs.  Not shown is expat itself.
> > 
> > Any comments?  I will hold off on this patch for a little while, at least
> > until one of the expat clients is ready.

My main concern here, is how much the new xml-based developments this
will grow GDB.  Linking the final gdb executable is already getting
problematic on small memory systems.  How big is libexpat.a, and how
much does a flash-enabled GDB grow?

Another question I have is about how we think to handle expat in the
future.  Is expat still undergoing much development?  Are you planning
to update expat regularly?

Mark

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Sun, Jul 23, 2006 at 11:51:56PM +0200, Mark Kettenis wrote:
> My main concern here, is how much the new xml-based developments this
> will grow GDB.  Linking the final gdb executable is already getting
> problematic on small memory systems.  How big is libexpat.a, and how
> much does a flash-enabled GDB grow?

Ah, that's why I picked expat, instead of the more convenient DOM
implementations (which are huge).

On x86_64, libexpat.a is 600K, with debugging information enabled. 
Code size is only about 140K of that.  For comparison, remote.o is 70K
code size and 280K with debug info.  So it's two to three new files
worth of code - in my opinion, this is an acceptable cost.  What do you
think - workable?

> Another question I have is about how we think to handle expat in the
> future.  Is expat still undergoing much development?  Are you planning
> to update expat regularly?

Not particularly.  Expat 2.0.0 was released in January 2006, so it's
still maintained, but there haven't been any releases since then, so
it's not churning particularly.  I don't think it likely that we'll
need any cutting edge features from it, either.  My plan was to import
2.0.0 and leave it alone as much as possible, unless we encountered a
bug in it.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Christopher Faylor]

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.

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.

cgf

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Sun, Jul 23, 2006 at 06:40:32PM -0400, Christopher Faylor wrote:
> 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.
> 
> 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.

I'm going to let you and Mark argue this one out, I'm afraid.

We (CodeSourcery) chose to use XML for a couple of projects in order to
avoid wheel reduplication.  Which means using a pre-written library.
Personally, I think a simple list of libraries that users need in order
to build GDB would be reasonable.  But I was quite specifically told
that other GDB developers (Mark definitely said this - I'm not sure if
Eli did also) were unhappy at the idea of requiring external libraries. 
So I added it to src.

I'd be happy to dump that and put it in the "Installing GDB" chapter of
the manual (and NEWS) instead.  It's not like it's a pain to build; it
configures out of the box everywhere I've tried it.  I like the idea of
using more preinstalled libraries, in general, and as long as we bother
to document our requirements I don't see the problem.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Christopher Faylor]

On Sun, Jul 23, 2006 at 06:57:12PM -0400, Daniel Jacobowitz wrote:
>On Sun, Jul 23, 2006 at 06:40:32PM -0400, Christopher Faylor wrote:
>> 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.
>> 
>> 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.
>
>I'm going to let you and Mark argue this one out, I'm afraid.
>
>We (CodeSourcery) chose to use XML for a couple of projects in order to
>avoid wheel reduplication.  Which means using a pre-written library.
>Personally, I think a simple list of libraries that users need in order
>to build GDB would be reasonable.  But I was quite specifically told
>that other GDB developers (Mark definitely said this - I'm not sure if
>Eli did also) were unhappy at the idea of requiring external libraries.
>So I added it to src.

I obviously missed that discussion, but if it occurred during the time
that I think it did, I have a very good excuse for missing it.

I found your initial announcement about expat but I didn't see (and
actually can't yet find) any discussion about putting expat in 'src'.

Is there a major operating system which doesn't have it easily
available?  And, even if there is, why is gdb different from any other
project out there which might rely on expat?  Would a tool that downloads
expat source from an official web site and builds it be acceptable?

cgf

Re: [RFC] Add expat to the GDB sources

[Pedro Alves]

Daniel Jacobowitz wrote:
> We (CodeSourcery) chose to use XML for a couple of projects in order to
> avoid wheel reduplication.
>   

Can't resist, must say:
XML sucks for line based merging/patching.

There, I said it. Going to hide in the closet.

Cheers,
Pedro Alves

Re: [RFC] Add expat to the GDB sources

[Mark Kettenis]

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

Depending on an external expat would be acceptable for me if the bits
of GDB that depend on it would become optional, such that we can
choose not to build them if expat is not available.

Mark

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Mon, Jul 24, 2006 at 01:18:31AM +0200, Mark Kettenis wrote:
> 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 don't think this is a high cost, I really don't.  We should document
our own requirements clearly.  If we have requirements that themselves
have complicated dependency chains - I don't know if we will - then we
can even document that.

> Depending on an external expat would be acceptable for me if the bits
> of GDB that depend on it would become optional, such that we can
> choose not to build them if expat is not available.

That's far more error-prone than either alternative.  You complained
about the cost of testing the detection code, which I think is pretty
trivial; but this would require testing two different code paths in GDB
itself, and fielding "my flash doesn't work" bug reports from people
who failed to link against expat.

For scripting language support, I've been considering optional
dependencies, but for absolutely everything else I think we should
avoid them.  Ship it, or require it at configure time, please.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Sun, Jul 23, 2006 at 07:13:20PM -0400, Christopher Faylor wrote:
> I found your initial announcement about expat but I didn't see (and
> actually can't yet find) any discussion about putting expat in 'src'.

There wasn't much of one:
  http://sourceware.org/ml/gdb/2006-01/msg00273.html
  http://sourceware.org/ml/gdb/2006-01/msg00276.html

I think there was an earlier one, but perhaps not.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Joel Brobecker]

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

Plus: Having it in our source tree allows us to have a good knowledge
and control of what we have. What if a user has a whather-distro-modified
version of libexpat and this version has a big bug in it? Or what if
the current released version has a bug that we just fixed? I think
not having it in our tree makes it more difficult for our users
to build GDB, and that should also count.

I don't want to make a policy of it, but having something as small
as libexpat, especially since it doesn't seem to be evolving much,
seems better than documenting the requirement of having it installed
on the system.

So even thought we should make a decision on a case by case basis,
I would be inclined in this case to include libexpat. I don't think
we're actually doing a fork. I think it's like readline: we try to
push the patch to the authors first before putting it in our copy.

-- 
Joel

Re: [RFC] Add expat to the GDB sources

[Christopher Faylor]

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

Re: [RFC] Add expat to the GDB sources

[Christopher Faylor]

On Sun, Jul 23, 2006 at 11:20:04PM -0700, Joel Brobecker wrote:
>> 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.
>
>Plus: Having it in our source tree allows us to have a good knowledge
>and control of what we have. What if a user has a whather-distro-modified
>version of libexpat and this version has a big bug in it? Or what if
>the current released version has a bug that we just fixed? I think
>not having it in our tree makes it more difficult for our users
>to build GDB, and that should also count.

You can make similar statements about any of the libraries which gdb
uses, like ncurses or glibc.  And, you can flip it around, too.  Distros
are apt to fix bugs when they are detected.  Are we going to have someone
scanning bugtraq, the expat web site, and the
Fedora/Gentoo/Ubuntu/Debian web sites looking for updates?

>I don't want to make a policy of it, but having something as small
>as libexpat, especially since it doesn't seem to be evolving much,
>seems better than documenting the requirement of having it installed
>on the system.

So, if expat is small and not evolving it is not apt to have a big bug
in it...

>So even thought we should make a decision on a case by case basis,
>I would be inclined in this case to include libexpat. I don't think
>we're actually doing a fork. I think it's like readline: we try to
>push the patch to the authors first before putting it in our copy.

But readline has been a fork for a long time and, since it is statically
compiled into gdb, we don't see the benefit of the readline shared
library, we don't see any improvements in new distro releases, and we
need to use gdb manpower resources to keep it up-to-date.

There is also the meta issue here of assuming that gdb owns the 'src'
directory and has the right to put things there without discussion with
the other projects who use the directory.  IMO, the polite thing to do is
to mention this to the other projects.

cgf

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Mon, Jul 24, 2006 at 11:30:17AM -0400, Christopher Faylor wrote:
> You can make similar statements about any of the libraries which gdb
> uses, like ncurses or glibc.  And, you can flip it around, too.  Distros
> are apt to fix bugs when they are detected.  Are we going to have someone
> scanning bugtraq, the expat web site, and the
> Fedora/Gentoo/Ubuntu/Debian web sites looking for updates?

For the record, Debian has a strict policy against this sort of
inclusion.  We already do not use the readline shipped with GDB. I do
not plan to use GDB's expat, either, if it ends up included.

> >So even thought we should make a decision on a case by case basis,
> >I would be inclined in this case to include libexpat. I don't think
> >we're actually doing a fork. I think it's like readline: we try to
> >push the patch to the authors first before putting it in our copy.
> 
> But readline has been a fork for a long time and, since it is statically

Actually, at my latest merge the local changes to readline were fairly
small.  I believe most of them were for either DJGPP or Cygwin.

> There is also the meta issue here of assuming that gdb owns the 'src'
> directory and has the right to put things there without discussion with
> the other projects who use the directory.  IMO, the polite thing to do is
> to mention this to the other projects.

I can if you want, but (A) there's no overall src mailing list,
despite at least one attempt to make one, and (B) it won't get in
anyone else's way, so I'm not sure why.  But I'll wait and see how this
discussion progresses, first.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Christopher Faylor]

On Mon, Jul 24, 2006 at 11:49:59AM -0400, Daniel Jacobowitz wrote:
>On Mon, Jul 24, 2006 at 11:30:17AM -0400, Christopher Faylor wrote:
>>You can make similar statements about any of the libraries which gdb
>>uses, like ncurses or glibc.  And, you can flip it around, too.
>>Distros are apt to fix bugs when they are detected.  Are we going to
>>have someone scanning bugtraq, the expat web site, and the
>>Fedora/Gentoo/Ubuntu/Debian web sites looking for updates?
>
>For the record, Debian has a strict policy against this sort of
>inclusion.  We already do not use the readline shipped with GDB.  I do
>not plan to use GDB's expat, either, if it ends up included.

Huh.  Interesting.  Good for Debian.

>> >So even thought we should make a decision on a case by case basis,
>> >I would be inclined in this case to include libexpat. I don't think
>> >we're actually doing a fork. I think it's like readline: we try to
>> >push the patch to the authors first before putting it in our copy.
>> 
>> But readline has been a fork for a long time and, since it is statically
>
>Actually, at my latest merge the local changes to readline were fairly
>small.  I believe most of them were for either DJGPP or Cygwin.

Right.  I know that.  I see the convergence but still I think my point
stands.

>>There is also the meta issue here of assuming that gdb owns the 'src'
>>directory and has the right to put things there without discussion with
>>the other projects who use the directory.  IMO, the polite thing to do
>>is to mention this to the other projects.
>
>I can if you want, but (A) there's no overall src mailing list, despite
>at least one attempt to make one, and (B) it won't get in anyone else's
>way, so I'm not sure why.  But I'll wait and see how this discussion
>progresses, first.

I *really* doubt that anyone would object but there is always the chance
that some other project was looking to use an xml library and might have
opinions on the subject.

I still don't understand why gdb is different from most other projects and
requires the existence of an in-tree library rather than just checking for
it via configure.

cgf

Re: [RFC] Add expat to the GDB sources

[Eli Zaretskii]

> Date: Mon, 24 Jul 2006 11:24:38 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> I would really like to see a day when 'src' will no longer include
> 'tcl', or 'readline', or 'expat'.

But the same could be said about libiberty, libbfd, and libopcodes.
Are you saying we should remove them, too, from the GDB distro?  If
not, what is the difference between those and readline?

Re: [RFC] Add expat to the GDB sources

[Eli Zaretskii]

> Date: Mon, 24 Jul 2006 11:49:59 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> > But readline has been a fork for a long time and, since it is statically
> 
> Actually, at my latest merge the local changes to readline were fairly
> small.  I believe most of them were for either DJGPP or Cygwin.

Yes.  If the readline maintainer merges these patches in the mainline,
we could terminate the fork.

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Mon, Jul 24, 2006 at 10:47:54PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 24 Jul 2006 11:24:38 -0400
> > From: Christopher Faylor <me@cgf.cx>
> > 
> > I would really like to see a day when 'src' will no longer include
> > 'tcl', or 'readline', or 'expat'.
> 
> But the same could be said about libiberty, libbfd, and libopcodes.
> Are you saying we should remove them, too, from the GDB distro?  If
> not, what is the difference between those and readline?

In my opinion, the difference is that no independent releases are made
of those projects.  In an ideal world, maybe there would be independent
releases, and we could use them.  But BFD in particular doesn't have a
stable API and (as recently discussed on the binutils list) doesn't
have an interest in one.

Compare to readline, tcl, and expat, each used by hundreds of different
programs.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Mon, Jul 24, 2006 at 10:50:00PM +0300, Eli Zaretskii wrote:
> > Date: Mon, 24 Jul 2006 11:49:59 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > > But readline has been a fork for a long time and, since it is statically
> > 
> > Actually, at my latest merge the local changes to readline were fairly
> > small.  I believe most of them were for either DJGPP or Cygwin.
> 
> Yes.  If the readline maintainer merges these patches in the mainline,
> we could terminate the fork.

I would welcome someone taking the time to look over the remaining
changes and submit them to the readline maintainer.  I believe I did
submit the non-DJGPP-or-Cygwin-related changes, either that or there
weren't any left that mattered.  It's a great idea!

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Christopher Faylor]

On Mon, Jul 24, 2006 at 03:51:18PM -0400, Daniel Jacobowitz wrote:
>On Mon, Jul 24, 2006 at 10:47:54PM +0300, Eli Zaretskii wrote:
>>>Date: Mon, 24 Jul 2006 11:24:38 -0400 From: Christopher Faylor
>>>
>>>I would really like to see a day when 'src' will no longer include
>>>'tcl', or 'readline', or 'expat'.
>>
>>But the same could be said about libiberty, libbfd, and libopcodes.
>>Are you saying we should remove them, too, from the GDB distro?  If
>>not, what is the difference between those and readline?
>
>In my opinion, the difference is that no independent releases are made
>of those projects.  In an ideal world, maybe there would be independent
>releases, and we could use them.  But BFD in particular doesn't have a
>stable API and (as recently discussed on the binutils list) doesn't
>have an interest in one.
>
>Compare to readline, tcl, and expat, each used by hundreds of different
>programs.

Yes.

Also, the master repository for libiberty, et al, is *on sourceware* not
on some random other server and all of the people who make changes to
the libraries participate in forums which are clustered around
sourceware and are known to each other.  This is not the case for tcl or
expat, and only somewhat the case for readline.

cgf

Re: [RFC] Add expat to the GDB sources

[Eli Zaretskii]

> Date: Mon, 24 Jul 2006 15:52:26 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sourceware.org, cgf-gdb-patches@sourceware.org
> 
> On Mon, Jul 24, 2006 at 10:50:00PM +0300, Eli Zaretskii wrote:
> > > Date: Mon, 24 Jul 2006 11:49:59 -0400
> > > From: Daniel Jacobowitz <drow@false.org>
> > > 
> > > > But readline has been a fork for a long time and, since it is statically
> > > 
> > > Actually, at my latest merge the local changes to readline were fairly
> > > small.  I believe most of them were for either DJGPP or Cygwin.
> > 
> > Yes.  If the readline maintainer merges these patches in the mainline,
> > we could terminate the fork.
> 
> I would welcome someone taking the time to look over the remaining
> changes and submit them to the readline maintainer.

I think they were submitted a long time ago.

Re: [RFC] Add expat to the GDB sources

[Eli Zaretskii]

> Date: Mon, 24 Jul 2006 15:51:18 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: cgf-gdb-patches@sourceware.org, gdb-patches@sourceware.org
> 
> On Mon, Jul 24, 2006 at 10:47:54PM +0300, Eli Zaretskii wrote:
> > > Date: Mon, 24 Jul 2006 11:24:38 -0400
> > > From: Christopher Faylor <me@cgf.cx>
> > > 
> > > I would really like to see a day when 'src' will no longer include
> > > 'tcl', or 'readline', or 'expat'.
> > 
> > But the same could be said about libiberty, libbfd, and libopcodes.
> > Are you saying we should remove them, too, from the GDB distro?  If
> > not, what is the difference between those and readline?
> 
> In my opinion, the difference is that no independent releases are made
> of those projects.

They come with GCC and with Binutils.

Also, you seem to be saying that, once we remove readline, say, one
would have to use the last released version of readline for building
GDB, while the build out of CVS will still use the CVS version, is
that right?  If so, it's a bad idea, IMHO.

> In an ideal world, maybe there would be independent
> releases, and we could use them.  But BFD in particular doesn't have a
> stable API and (as recently discussed on the binutils list) doesn't
> have an interest in one.
> 
> Compare to readline, tcl, and expat, each used by hundreds of different
> programs.

Sorry, I don't see any significant difference.  The number of packages
is not really relevant; what is relevant is how easier or harder would
things become for Joe Random Hacker Who Just Wants To Build GDB.
Perhaps Chris and Daniel don't see any problem because they have the
latest versions of everything on their machines, at all times.  From
my point of view, about the worst annoyance of Free Software is what
happens when I "./configure; make" just to find out that I need two
more packages, which in turn want each one two more packages, which
want yet some more ...

This is where I usually tell myself "Welcome to Free Software, where
maintainers care about users much less than they care about their own
convenience".  (Present company excluded, of course.)

In other words, when I download a package, I want it ideally to build
out of the box, period.  No questions asked, and no additional
prerequisites that could turn a simple build job into an agony that
lasts the better part of my day, because each prerequisite package
needs a bit of tweaking to build and install properly.  By contrast,
when I get readline etc. with GDB, I can be _certain_ that someone
already tried and succeeded to build _this_ version of the library
with _this_ configury and _this_ GDB release.

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Mon, Jul 24, 2006 at 11:29:26PM +0300, Eli Zaretskii wrote:
> I think they were submitted a long time ago.

If there's any one thing we've learned from running gdb-patches,
it's that it is occasionally necessary to try again :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Mon, Jul 24, 2006 at 11:28:53PM +0300, Eli Zaretskii wrote:
> They come with GCC and with Binutils.

Yes, that's true.  But they also come with instructions that their
development headers should not be installed, and by default 'make
install' does not install them - precisely because they're not meant to
be used this way.

> Also, you seem to be saying that, once we remove readline, say, one
> would have to use the last released version of readline for building
> GDB, while the build out of CVS will still use the CVS version, is
> that right?  If so, it's a bad idea, IMHO.

I apologize if I gave that impression!  Neither CVS nor released GDB
tarballs would go out and download readline for you; both would use the
same thing, i.e. what you have installed.

This can be a pain if you have tight version requirements on the
supported libraries; but we don't.  We've worked with the last several
years of releases of readline, for instance, basically without change.

> > In an ideal world, maybe there would be independent
> > releases, and we could use them.  But BFD in particular doesn't have a
> > stable API and (as recently discussed on the binutils list) doesn't
> > have an interest in one.
> > 
> > Compare to readline, tcl, and expat, each used by hundreds of different
> > programs.
> 
> Sorry, I don't see any significant difference.  The number of packages
> is not really relevant; what is relevant is how easier or harder would
> things become for Joe Random Hacker Who Just Wants To Build GDB.
> Perhaps Chris and Daniel don't see any problem because they have the
> latest versions of everything on their machines, at all times.  From
> my point of view, about the worst annoyance of Free Software is what
> happens when I "./configure; make" just to find out that I need two
> more packages, which in turn want each one two more packages, which
> want yet some more ...

This is what installation documentation is for!  We already have a
section in the manual that covers running configure.

I don't always have things installed.  I confess that I do use a modern
packaging system that makes installing dependencies relatively
painless, but I do it by hand from time to time too.

And neither readline nor expat has a substantial dependency chain.

I wouldn't suggest that we require an installation of GNOME, on the
other hand.

> In other words, when I download a package, I want it ideally to build
> out of the box, period.  No questions asked, and no additional
> prerequisites that could turn a simple build job into an agony that
> lasts the better part of my day, because each prerequisite package
> needs a bit of tweaking to build and install properly.  By contrast,
> when I get readline etc. with GDB, I can be _certain_ that someone
> already tried and succeeded to build _this_ version of the library
> with _this_ configury and _this_ GDB release.

FYI, what we are doing with readline is against the FSF's recently
clarified policy.  We're shipping a locally modified copy of a GNU
package.  This was the subject of one of the past few messages to
gnu-prog.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Christopher Faylor]

On Mon, Jul 24, 2006 at 11:28:53PM +0300, Eli Zaretskii wrote:
>>Date: Mon, 24 Jul 2006 15:51:18 -0400
>>From: Daniel Jacobowitz
>>
>>On Mon, Jul 24, 2006 at 10:47:54PM +0300, Eli Zaretskii wrote:
>>>> Date: Mon, 24 Jul 2006 11:24:38 -0400
>>>> From: Christopher Faylor
>>>> 
>>>> I would really like to see a day when 'src' will no longer include
>>>> 'tcl', or 'readline', or 'expat'.
>>>
>>>But the same could be said about libiberty, libbfd, and libopcodes.
>>>Are you saying we should remove them, too, from the GDB distro?  If
>>>not, what is the difference between those and readline?
>>
>>In my opinion, the difference is that no independent releases are made
>>of those projects.
>
>They come with GCC and with Binutils.

AFAIK, the master for libbfd and libopcodes is in 'src'.  I think DJ
keeps libiberty in sync so that if you make a change to 'src' it also
shows up in 'gcc' and vice versa.

>Also, you seem to be saying that, once we remove readline, say, one
>would have to use the last released version of readline for building
>GDB, while the build out of CVS will still use the CVS version, is
>that right?  If so, it's a bad idea, IMHO.
>
>> In an ideal world, maybe there would be independent
>> releases, and we could use them.  But BFD in particular doesn't have a
>> stable API and (as recently discussed on the binutils list) doesn't
>> have an interest in one.
>> 
>> Compare to readline, tcl, and expat, each used by hundreds of different
>> programs.
>
>Sorry, I don't see any significant difference.  The number of packages
>is not really relevant; what is relevant is how easier or harder would
>things become for Joe Random Hacker Who Just Wants To Build GDB.

I would submit that this is not relevant either.  If Joe Random Hacker
can't follow instructions for downloading and building an additional
package then the chances are not high that he will be able to do any
real debugging.

It probably isn't really the case, but it sure seems like someone who
wants to build a debugger would be slightly more clueful than someone
who wants to build, e.g., mplayer.

Also, we're not talking about having to track down scores of packages,
we're talking about *one* package.  If we actually were talking about
adding about more packages it would actually make less sense to do
something like this.  'src' would be bloated and we'd be in constant
package update mode.

>Perhaps Chris and Daniel don't see any problem because they have the
>latest versions of everything on their machines, at all times.  From
>my point of view, about the worst annoyance of Free Software is what
>happens when I "./configure; make" just to find out that I need two
>more packages, which in turn want each one two more packages, which
>want yet some more ...
>
>This is where I usually tell myself "Welcome to Free Software, where
>maintainers care about users much less than they care about their own
>convenience".  (Present company excluded, of course.)

I have been in the dependency-chain situation MANY times before and I
have *exactly* the opposite feeling.  I'm actually pretty heartened to
see code reuse in the free software community when it could easily be
the other way around.  People could just be reimplementing, xml parsing
libraries endlessly rather than trying to use existing versions.

It sounds like you're advocating that every project which relies on
external libraries should include the source code for those libraries.
If that is the case, it means that we shouldn't bother with shared
libraries at all.  Every package would, instead, be bloated by the
inclusion of its own version of expat, and openssl, and libtiff, etc.

>In other words, when I download a package, I want it ideally to build
>out of the box, period.

IMO, that is an unrealistic expectation.

>No questions asked, and no additional prerequisites that could turn a
>simple build job into an agony that lasts the better part of my day,
>because each prerequisite package needs a bit of tweaking to build and
>install properly.  By contrast, when I get readline etc.  with GDB, I
>can be _certain_ that someone already tried and succeeded to build
>_this_ version of the library with _this_ configury and _this_ GDB
>release.

And, if you are on linux or windows, you can be certain that your
version of gdb has a different version of readline than every other
package on the system and that gdb is slightly bigger and possibly
slightly incompatible as a result.  I hate this about insight, also.
The problem is even worse there.  That is a standard problem with
including disparate versions of libraries.

But, where does this philosophy end?  Are you *really* advocating that
every shipping package should include the source code of any libraries
that they use?  So gdb should also include ncurses?

That seems wrong if for no other reason than bug fixes for the library
would require changing N packages rather than 1 package.

cgf

Re: [RFC] Add expat to the GDB sources

[Mark Kettenis]

> Date: Mon, 24 Jul 2006 12:37:00 -0400
> From: Christopher Faylor <cgf-gdb-patches@sourceware.org>
> 
> On Mon, Jul 24, 2006 at 11:49:59AM -0400, Daniel Jacobowitz wrote:
> >On Mon, Jul 24, 2006 at 11:30:17AM -0400, Christopher Faylor wrote:
> >>You can make similar statements about any of the libraries which gdb
> >>uses, like ncurses or glibc.  And, you can flip it around, too.
> >>Distros are apt to fix bugs when they are detected.  Are we going to
> >>have someone scanning bugtraq, the expat web site, and the
> >>Fedora/Gentoo/Ubuntu/Debian web sites looking for updates?
> >
> >For the record, Debian has a strict policy against this sort of
> >inclusion.  We already do not use the readline shipped with GDB.  I do
> >not plan to use GDB's expat, either, if it ends up included.
> 
> Huh.  Interesting.  Good for Debian.

We do something similar on OpenBSD.  For us this works pretty well,
because we ship both gdb and readline as part of the base system,
where we have complete control over the version of gdb and readline
that we ship, and do a lot of testing for the specific test setup
chosen.  That's a completely different situation from shipping a
.tar.gz on ftp.gnu.org that people will try to build on a very wide
variety of systems out there.

Re: [RFC] Add expat to the GDB sources

[Mark Kettenis]

> 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

Re: [RFC] Add expat to the GDB sources

[DJ Delorie]

> AFAIK, the master for libbfd and libopcodes is in 'src'.  I think DJ
> keeps libiberty in sync so that if you make a change to 'src' it also
> shows up in 'gcc' and vice versa.

FYI if you put it in src only, it vanishes.  It's strictly gcc->src.

> It sounds like you're advocating that every project which relies on
> external libraries should include the source code for those libraries.

As another point of view, what one of the other projects I'm on does
is (1) not include the libraries in the cvs tree, but (2) include a
copy of the latest official sources in the CD-ROMs we distribute.  The
installer knows you need them, but uses the installed ones if they're
available.  If not, a project-private copy is installed and used
instead.  Or, you can use the cd-rom copy to install a shared copy on
your system.

It's a balancing act between "don't screw the user by making it hard
to install" and "don't screw the user by installing bad copies of
common software".

Re: [RFC] Add expat to the GDB sources

[Mark Kettenis]

> Date: Mon, 24 Jul 2006 17:41:57 -0400
> From: Christopher Faylor <cgf-use-the-mailinglist-please@sourceware.org>
> 
> Also, we're not talking about having to track down scores of packages,
> we're talking about *one* package.  If we actually were talking about
> adding about more packages it would actually make less sense to do
> something like this.  'src' would be bloated and we'd be in constant
> package update mode.

Therefore we should not add random features to GDB that require more
"external" packages.

> It sounds like you're advocating that every project which relies on
> external libraries should include the source code for those libraries.
> If that is the case, it means that we shouldn't bother with shared
> libraries at all.  Every package would, instead, be bloated by the
> inclusion of its own version of expat, and openssl, and libtiff, etc.

Shared libraries are hard.  You can only do it right if you correctly
implement a version policy, which is almost impossible to do if you
don't have some sort of central control.  It really is only worth
doing if there are more than a handlful of different programs using
the same library that are likely to be used simultaniously.

> >In other words, when I download a package, I want it ideally to build
> >out of the box, period.
> 
> IMO, that is an unrealistic expectation.

But one that is true for the current GDB on many systems right now.

> >No questions asked, and no additional prerequisites that could turn a
> >simple build job into an agony that lasts the better part of my day,
> >because each prerequisite package needs a bit of tweaking to build and
> >install properly.  By contrast, when I get readline etc.  with GDB, I
> >can be _certain_ that someone already tried and succeeded to build
> >_this_ version of the library with _this_ configury and _this_ GDB
> >release.
> 
> And, if you are on linux or windows, you can be certain that your
> version of gdb has a different version of readline than every other
> package on the system and that gdb is slightly bigger and possibly
> slightly incompatible as a result.  I hate this about insight, also.
> The problem is even worse there.  That is a standard problem with
> including disparate versions of libraries.

A properly engineered Linux distribution solves this by building
everything, including gdb, with a properly chosen version of readline,
and testing this setup extensively.  When a user isn't satisfied with the 

> But, where does this philosophy end?  Are you *really* advocating that
> every shipping package should include the source code of any libraries
> that they use?  So gdb should also include ncurses?

The philosophy has always been that one should be able to build a GNU
toolchain without any external dependencies, to be able to bootstrap
into a situation wher you can use the toolchain to build other Free
Software.

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Tue, Jul 25, 2006 at 12:29:28AM +0200, Mark Kettenis wrote:
> > But, where does this philosophy end?  Are you *really* advocating that
> > every shipping package should include the source code of any libraries
> > that they use?  So gdb should also include ncurses?
> 
> The philosophy has always been that one should be able to build a GNU
> toolchain without any external dependencies, to be able to bootstrap
> into a situation wher you can use the toolchain to build other Free
> Software.

When was the last time you tried to build GCC?  Even just building it
has pretty hefty requirements:

  http://gcc.gnu.org/install/prerequisites.html

GMP/MPFR and zip fill the same sort of role that expat and readline
would.  The GNU Make version requirement also often needs to be
manually met by users wanting to build GCC - lots of systems don't have
an adequate Make for the GCC build system.

I don't think that expecting everything to come out of the box is
realistic any more.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Mon, Jul 24, 2006 at 06:34:13PM -0400, Daniel Jacobowitz wrote:
> I don't think that expecting everything to come out of the box is
> realistic any more.

I also don't think this discussion is going much of anywhere...

I'm done GDB hacking for today, but tomorrow I'm planning to come back
with a sample patch which uses out-of-tree expat and readline, and
makes it as easy as possible to build anyway.  Let's see if that makes
the situation clearer.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Mark Kettenis]

> Date: Mon, 24 Jul 2006 18:34:13 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Tue, Jul 25, 2006 at 12:29:28AM +0200, Mark Kettenis wrote:
> > > But, where does this philosophy end?  Are you *really* advocating that
> > > every shipping package should include the source code of any libraries
> > > that they use?  So gdb should also include ncurses?
> > 
> > The philosophy has always been that one should be able to build a GNU
> > toolchain without any external dependencies, to be able to bootstrap
> > into a situation wher you can use the toolchain to build other Free
> > Software.
> 
> When was the last time you tried to build GCC?  Even just building it
> has pretty hefty requirements:
> 
>   http://gcc.gnu.org/install/prerequisites.html
> 
> GMP/MPFR and zip fill the same sort of role that expat and readline
> would.  The GNU Make version requirement also often needs to be
> manually met by users wanting to build GCC - lots of systems don't have
> an adequate Make for the GCC build system.

Where do you think my frstration about external dependencies comes
from ;-).  However, GCC will build fine without most of those
packages: without GMP/MPFR you won't get gfortran, and without zip you
won't get gjc/libjava.  But at least you can still build the C
compiler, which you can then use to build the other dependencies.

I think the GNU Make requirements are a serious mistake by the GCC
developers.

Translated to GDB this would mean that without expat you'd still get a
usable gdb, but loose goodies like the new flash support (which isn't
terribly useful for a native gdb anyway).

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Tue, Jul 25, 2006 at 12:48:51AM +0200, Mark Kettenis wrote:
> Where do you think my frstration about external dependencies comes
> from ;-).  However, GCC will build fine without most of those
> packages: without GMP/MPFR you won't get gfortran, and without zip you
> won't get gjc/libjava.  But at least you can still build the C
> compiler, which you can then use to build the other dependencies.
> 
> I think the GNU Make requirements are a serious mistake by the GCC
> developers.

I don't.  I was there for the discussion that led to the current
requirements, and the reasoning was compelling.  Much of it was in
person (at the Summit) and so there's limited transcripts.  But
it may not have been my best choice of example; I don't know if you
ever had to work with the internals of the GCC build system before they
adopted the GNU make requirement.  And they're still improving to take
advantage of even more useful GNU make features to simplify their build
system to the point where developers in other areas can often grok
what's going on.  Well, not there yet.

> Translated to GDB this would mean that without expat you'd still get a
> usable gdb, but loose goodies like the new flash support (which isn't
> terribly useful for a native gdb anyway).

I dislike this idea, as I've said before:

  - for the same reason I dislike #if.  The code is far more likely to
    rot if you can build GDB with it preprocessed or Makefile'd out.

  - for the bug reports we'll get where GDB mysteriously fails to have
    some feature.

But that's not the end of the world; if the outcome of this discussion
is that conditionalizing features is preferable to bundling expat, I'm
willing to adjust it to do so.  I'd spit out a big warning at the end
of configure if expat was not found.  And probably warnings during
debug sessions if the expat code paths would have triggered.

... And maybe rethink using the minimal expat versus the more
feature-complete libxml2, but I'd need to talk to Vladimir about that;
he's written XML parsers more recently than I have now.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Christopher Faylor]

On Mon, Jul 24, 2006 at 06:37:27PM -0400, Daniel Jacobowitz wrote:
>On Mon, Jul 24, 2006 at 06:34:13PM -0400, Daniel Jacobowitz wrote:
>> I don't think that expecting everything to come out of the box is
>> realistic any more.
>
>I also don't think this discussion is going much of anywhere...
>
>I'm done GDB hacking for today, but tomorrow I'm planning to come back
>with a sample patch which uses out-of-tree expat and readline, and
>makes it as easy as possible to build anyway.  Let's see if that makes
>the situation clearer.

Actual examples?  Nah.  That will never work.

cgf

Re: [RFC] Add expat to the GDB sources

[Christopher Faylor]

On Tue, Jul 25, 2006 at 12:29:28AM +0200, Mark Kettenis wrote:
>cgf wrote:
>>It sounds like you're advocating that every project which relies on
>>external libraries should include the source code for those libraries.
>>If that is the case, it means that we shouldn't bother with shared
>>libraries at all.  Every package would, instead, be bloated by the
>>inclusion of its own version of expat, and openssl, and libtiff, etc.
>
>Shared libraries are hard.  You can only do it right if you correctly
>implement a version policy, which is almost impossible to do if you
>don't have some sort of central control.  It really is only worth
>doing if there are more than a handlful of different programs using
>the same library that are likely to be used simultaniously.

The only way I can make sense of the above paragraph is if you were
thinking that I wanted gdb to produce shared libraries.  I'm not talking
about having gdb produce shared libraries for readline and expat.  There
would be little point in doing that.

What I was saying was that if you carry the "no external dependencies"
to every other package on the system then there is very little need
for shared libraries since every package will have its own version
of the packages it needs.

So, shared libraries are not hard.  You rely on the distro to do the
right thing just like you rely on the distro to produce a usable gcc.
Then the packages that come with the distro should use the shared
libraries rather than rolling their own version of the libraries.

cgf

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Tue, Jul 25, 2006 at 12:29:28AM +0200, Mark Kettenis wrote:
> > But, where does this philosophy end?  Are you *really* advocating that
> > every shipping package should include the source code of any libraries
> > that they use?  So gdb should also include ncurses?
> 
> The philosophy has always been that one should be able to build a GNU
> toolchain without any external dependencies, to be able to bootstrap
> into a situation wher you can use the toolchain to build other Free
> Software.

(I don't think toolchain in this sense includes GDB.)

Before I work on alternatives for using expat, which I'll be doing
later this afternoon, let me update us on the GNU philosophy on such
issues:

http://www.gnu.org/prep/maintain/html_node/External-Libraries.html#External-Libraries

(quoted below)

While this is not explicit, RMS has made clear that he also disapproves
of GNU packages including other GNU packages without special permission
permission from the FSF, especially if they have local modifications.
Which we do.  We have our own fork of readline.

Examples:
  - Fastjar was removed from GCC by FSF request; this is an equivalent
    issue to expat.  So we should not bundle expat.
  - libgcc-math was removed from GCC by FSF request, because it
    duplicated and slightly modified code from glibc; I believe this
    is equivalent to readline.
  - Soft-fp code from GCC was imported for use in the GCC runtime
    libraries on non-glibc systems, but only after direct permission
    from RMS.

I realize this is somewhat inconvenient for users of GDB, but I think
that if we asked the FSF, they would request we stop bundling readline,
and not bundle expat.

As for optional versus required, I don't think there's a relevant FSF
position.  However, I very much wanted to use the XML target
descriptions in some cases to replace the C-coded ones.  So obviously
I prefer to require expat.

====
So the thing to do in this case is to make your program use the module,
but not consider it a part of your program. There are two reasonable
methods of doing this:

   1. Assume the module is already installed on the system, and use it
when linking your program. This is only reasonable if the module really
has the form of a library.
   2. Include the module in your package, putting the source in a
separate subdirectory whose README file says, This is not part of the
GNU FOO program, but is used with GNU FOO. Then set up your makefiles
to build this module and link it into the executable.

      For this method, it is not necessary to treat the module as a
library and make a .a file from it. You can link with the .o files
directly in the usual manner. 

Both of these methods create an irregularity, and our lawyers have told
us to minimize the amount of such irregularity. So consider using these
methods only for general-purpose modules that were written for other
programs and released separately for general use. For anything that was
written as a contribution to your package, please get papers signed.
====

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Mon, Jul 31, 2006 at 01:33:12PM -0400, Daniel Jacobowitz wrote:
> As for optional versus required, I don't think there's a relevant FSF
> position.  However, I very much wanted to use the XML target
> descriptions in some cases to replace the C-coded ones.  So obviously
> I prefer to require expat.

Which yields this patch.

If our final decision is to make all features which require expat
optional, I can rework this patch to only issue a warning message,
and update the documentation accordingly.  It currently:
  - Searches $prefix/lib and $prefix/include for expat, as well
    as the standard system directories.
  - Offers a documented option to find expat elsewhere.
  - Defines HAVE_LIBEXPAT in config.h.

I think I've said everything useful that I can say on this subject;
I am not sure how to proceed.  The options that I see are:

  1. Refuse to use external libraries.
  2. Make external libraries optional.
  3. Require external libraries, with moderation and documentation.

Obviously I prefer 3, followed by 2.

Your thoughts welcome!

-- 
Daniel Jacobowitz
CodeSourcery

2006-07-31  Daniel Jacobowitz  <dan@codesourcery.com>

	* configure.ac: Check for expat.
	* acinclude.m4: Include AC_LIB_HAVE_LINKFLAGS dependencies.
	* Makefile.in (LIBEXPAT): New.
	(CLIBS): Include $(LIBEXPAT).
	* README: Mention expat.
	* configure, config.in: Regenerated.

2006-07-31  Daniel Jacobowitz  <dan@codesourcery.com>

	* gdb.texinfo (Installing GDB): Update menu.  Move text to...
	(Running Configure): ...here.
	(Requirements): New node.  Mention expat.

Index: configure.ac
===================================================================
RCS file: /cvs/src/src/gdb/configure.ac,v
retrieving revision 1.33
diff -u -p -r1.33 configure.ac
--- configure.ac	31 May 2006 15:14:37 -0000	1.33
+++ configure.ac	31 Jul 2006 20:01:59 -0000
@@ -315,6 +315,21 @@ if test "$ac_cv_search_tgetent" = no; th
   AC_MSG_ERROR([no termcap library found])
 fi
 
+AC_LIB_HAVE_LINKFLAGS([expat], [], [#include "expat.h"],
+		      [XML_Parser p = XML_ParserCreate (0);])
+if test "$HAVE_LIBEXPAT" != yes; then
+  missing_libraries=true
+  AC_MSG_NOTICE([expat appears to be missing.
+
+Expat is available from:
+  http://expat.sourceforge.net/
+])
+fi
+
+if test -n "$missing_libraries"; then
+  AC_MSG_ERROR([missing libraries])
+fi
+
 # ------------------------- #
 # Checks for header files.  #
 # ------------------------- #
Index: acinclude.m4
===================================================================
RCS file: /cvs/src/src/gdb/acinclude.m4,v
retrieving revision 1.15
diff -u -p -r1.15 acinclude.m4
--- acinclude.m4	31 May 2006 15:14:36 -0000	1.15
+++ acinclude.m4	31 Jul 2006 20:02:00 -0000
@@ -12,6 +12,11 @@ sinclude(../config/stdint.m4)
 
 sinclude(../config/gettext-sister.m4)
 
+dnl For AC_LIB_HAVE_LINKFLAGS.
+sinclude(../config/lib-ld.m4)
+sinclude(../config/lib-prefix.m4)
+sinclude(../config/lib-link.m4)
+
 dnl CYGNUS LOCAL: This gets the right posix flag for gcc
 AC_DEFUN([CY_AC_TCL_LYNX_POSIX],
 [AC_REQUIRE([AC_PROG_CC])AC_REQUIRE([AC_PROG_CPP])
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.833
diff -u -p -r1.833 Makefile.in
--- Makefile.in	19 Jul 2006 23:23:35 -0000	1.833
+++ Makefile.in	31 Jul 2006 20:02:00 -0000
@@ -128,6 +128,9 @@ READLINE = $(READLINE_DIR)/libreadline.a
 READLINE_SRC = $(srcdir)/$(READLINE_DIR)
 READLINE_CFLAGS = -I$(READLINE_SRC)/..
 
+# Where is expat?
+LIBEXPAT = @LIBEXPAT@
+
 WARN_CFLAGS = @WARN_CFLAGS@
 WERROR_CFLAGS = @WERROR_CFLAGS@
 GDB_WARN_CFLAGS = $(WARN_CFLAGS)
@@ -376,7 +379,7 @@ INSTALLED_LIBS=-lbfd -lreadline -lopcode
 	-lintl -liberty
 CLIBS = $(SIM) $(READLINE) $(OPCODES) $(BFD) $(INTL) $(LIBIBERTY) \
 	$(XM_CLIBS) $(TM_CLIBS) $(NAT_CLIBS) $(GDBTKLIBS) @LIBS@ \
-	$(LIBICONV) \
+	$(LIBICONV) $(LIBEXPAT) \
 	$(LIBIBERTY) $(WIN32LIBS)
 CDEPS = $(XM_CDEPS) $(TM_CDEPS) $(NAT_CDEPS) $(SIM) $(BFD) $(READLINE) \
 	$(OPCODES) $(INTL_DEPS) $(LIBIBERTY) $(CONFIG_DEPS)
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.345
diff -u -p -r1.345 gdb.texinfo
--- doc/gdb.texinfo	21 Jul 2006 14:46:55 -0000	1.345
+++ doc/gdb.texinfo	31 Jul 2006 20:16:26 -0000
@@ -21904,10 +21904,41 @@ Then give @file{gdb.dvi} to your @sc{dvi
 
 @node Installing GDB
 @appendix Installing @value{GDBN}
-@cindex configuring @value{GDBN}
 @cindex installation
-@cindex configuring @value{GDBN}, and source tree subdirectories
 
+@menu
+* Requirements::                Requirements for building @value{GDBN}
+* Running Configure::           Invoking the @value{GDBN} @code{configure} script
+* Separate Objdir::             Compiling @value{GDBN} in another directory
+* Config Names::                Specifying names for hosts and targets
+* Configure Options::           Summary of options for configure
+@end menu
+
+@node Requirements
+@section Requirements for building @value{GDBN}
+
+Building @value{GDBN} requires various tools and packages to be available.
+
+@heading Tools/packages necessary for building @value{GDBN}
+@table @asis
+@item ISO C90 compiler
+@value{GDBN} is written in ISO C90.  It should be buildable with any
+working C90 compiler, e.g.@: GCC.
+
+@item Expat
+@value{GDBN} uses the Expat XML parsing library.  This library may be
+included with your operating system distribution; if it is not, you
+can get the latest version from @url{http://expat.sourceforge.net}.
+The @code{configure} script will search for this library in several
+standard locations; if it is installed in an unusual path, you can
+use the @samp{--with-libexpat-prefix} option to specify its location.
+
+@end table
+
+@node Running Configure
+@section Invoking the @value{GDBN} @code{configure} script
+@cindex configuring @value{GDBN}
+@cindex configuring @value{GDBN}, and source tree subdirectories
 @value{GDBN} comes with a @code{configure} script that automates the process
 of preparing @value{GDBN} for installation; you can then use @code{make} to
 build the @code{gdb} program.
@@ -22013,12 +22044,6 @@ the @samp{SHELL} environment variable) i
 that @value{GDBN} uses the shell to start your program---some systems refuse to
 let @value{GDBN} debug child processes whose programs are not readable.
 
-@menu
-* Separate Objdir::             Compiling @value{GDBN} in another directory
-* Config Names::                Specifying names for hosts and targets
-* Configure Options::           Summary of options for configure
-@end menu
-
 @node Separate Objdir
 @section Compiling @value{GDBN} in another directory
 
Index: README
===================================================================
RCS file: /cvs/src/src/gdb/README,v
retrieving revision 1.36
diff -u -p -r1.36 README
--- README	17 May 2006 14:40:39 -0000	1.36
+++ README	31 Jul 2006 20:18:12 -0000
@@ -89,6 +89,9 @@ C compiler for your system, you may be a
 the GNU CC compiler.  It is available via anonymous FTP from the
 directory `ftp://ftp.gnu.org/pub/gnu/gcc'.
 
+   GDB also requires Expat, an XML parsing library.  The latest version
+of Expat should be available from `http://expat.sourceforge.net'.
+
    GDB can be used as a cross-debugger, running on a machine of one
 type while debugging a program running on a machine of another type.
 See below.

Re: [RFC] Add expat to the GDB sources

[Christopher Faylor]

On Mon, Jul 31, 2006 at 04:24:22PM -0400, Daniel Jacobowitz wrote:
>On Mon, Jul 31, 2006 at 01:33:12PM -0400, Daniel Jacobowitz wrote:
>>As for optional versus required, I don't think there's a relevant FSF
>>position.  However, I very much wanted to use the XML target
>>descriptions in some cases to replace the C-coded ones.  So obviously I
>>prefer to require expat.
>
>Which yields this patch.
>
>If our final decision is to make all features which require expat
>optional, I can rework this patch to only issue a warning message, and
>update the documentation accordingly.  It currently:
>  - Searches $prefix/lib and $prefix/include for expat, as well
>    as the standard system directories.
>  - Offers a documented option to find expat elsewhere.
>  - Defines HAVE_LIBEXPAT in config.h.
>
>I think I've said everything useful that I can say on this subject; I
>am not sure how to proceed.  The options that I see are:
>
>  1. Refuse to use external libraries.
>  2. Make external libraries optional.
>  3. Require external libraries, with moderation and documentation.
>
>Obviously I prefer 3, followed by 2.
>
>Your thoughts welcome!

FWIW, I have the same preferences.  Possibly we could also monitor the
situation, and if there is too much confusion caused by 3, then look into
implementing 2.

cgf

Re: [RFC] Add expat to the GDB sources

[Mark Kettenis]

> Date: Mon, 31 Jul 2006 16:24:22 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Mon, Jul 31, 2006 at 01:33:12PM -0400, Daniel Jacobowitz wrote:
> > As for optional versus required, I don't think there's a relevant FSF
> > position.  However, I very much wanted to use the XML target
> > descriptions in some cases to replace the C-coded ones.  So obviously
> > I prefer to require expat.
> 
> Which yields this patch.
> 
> If our final decision is to make all features which require expat
> optional, I can rework this patch to only issue a warning message,
> and update the documentation accordingly.  It currently:
>   - Searches $prefix/lib and $prefix/include for expat, as well
>     as the standard system directories.
>   - Offers a documented option to find expat elsewhere.
>   - Defines HAVE_LIBEXPAT in config.h.
> 
> I think I've said everything useful that I can say on this subject;
> I am not sure how to proceed.  The options that I see are:
> 
>   1. Refuse to use external libraries.
>   2. Make external libraries optional.
>   3. Require external libraries, with moderation and documentation.
> 
> Obviously I prefer 3, followed by 2.
> 
> Your thoughts welcome!

It all depends on what the external library is used for.  Making
readline optional wouldn't make much sense, since it is used for GDB's
primary user interface.  Making expat optional make much more sense to
me, as I can't see why I'd need it for a native debugger.

There's another reason why I'd like to see expat as an optional
library.  Currently we (OpenBSD) ship GDB in our base system.  This
would mean we'd have to include expat in our base system too;
something we'd rather not do especially if it doesn't give us any
benefits.  NetBSD and FreeBSD are in a similar situation I guess.

That said, I'm willing to give in under two conditions:

1. We add the necessary glue to the toplevel configure such that it
   accepts a --with-expat-dir option similar to the --with-gmp-dir
   option that's already there for GCC.  This will make it possible to
   keep building everything in one tree, which would come close to
   removing the objections I raised earlier about problemms installing
   expat on systems I use to test GDB on.

2. Try to keep the bits that need expat "optional", and review whether
   the code that needs it really benefits all of us, or only a few.

Mark

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

Thanks for responding!

On Mon, Jul 31, 2006 at 11:32:51PM +0200, Mark Kettenis wrote:
> It all depends on what the external library is used for.  Making
> readline optional wouldn't make much sense, since it is used for GDB's
> primary user interface.  Making expat optional make much more sense to
> me, as I can't see why I'd need it for a native debugger.

I've tried to explain this a couple of times, but I've been a bit
oblique about it.  Here's a clearer attempt, I hope.

The XML descriptions that I'm using for remote targets also encapsulate
information that is useful natively.  They could replace some chunks of
C code in the gdbarch vector, like the bits which adjust NUM_REGS based
on whether SSE/Altivec/FooExt are present, with simpler and more
uniform mechanisms.  And e.g. gdbarch_register_name would also be
covered by the textual description.

For you or me, that's not a particularly big deal.  We know where all
the bits go in existing ports.  But this sort of thing makes it easier
to retarget GDB for custom use, for people who are less familiar with
GDB.

That's not a business concern speaking, if you're wondering - purely
FSF hat.  It's not particularly in CodeSourcery's interest to make GDB
easier to port for people not familiar with it, but I still think it's
a Good Idea.  I get the feeling from your "good of the few" comments
that you're sometimes suspicious of our goals, which I think is really
unfortunate.  Whenever I'm working on the FSF gdb, rather than our
various local branches, I try to keep the goals of the FSF gdb project
in front of me.

And I think the consistency would be really nice, too - delete a few
of the internal interfaces and bundle them up into a clearer and
better documented approach.

And there's automated validation and such that you can do on data files
that isn't possible on C (or is much harder).

I used to think that most of the data-driven approach that I'm
advocating here was basically worthless, but I've been forcibly exposed
to modern software development a couple of times recently, and it
really is a nicer way to work in a lot of ways.

> That said, I'm willing to give in under two conditions:
> 
> 1. We add the necessary glue to the toplevel configure such that it
>    accepts a --with-expat-dir option similar to the --with-gmp-dir
>    option that's already there for GCC.  This will make it possible to
>    keep building everything in one tree, which would come close to
>    removing the objections I raised earlier about problemms installing
>    expat on systems I use to test GDB on.

Did you know that the --with-gmp-dir option doesn't build anything
automatically?  It has to be already built before you can configure
GCC; it does test -f in the specified directory and uses AC_TRY_LINK.

Here's how you'd build them separately with the patch I posted:

  ../expat/configure --prefix=/home/me/gdb-install
  make
  make install

  <elsewhere>

  ../gdb/configure --prefix=/home/me/gdb-install
  make # Will successfully find expat

If that's what you'd like for expat also, I can implement it, but
it's somewhat less useful than what I think you were describing.

Unfortunately you can't take an expat tarball and drop it into the src
tree and have it just build, which is another option.  That requires
a patch, since expat's makefiles do something fairly silly with
CFLAGS that would be a GNU Coding Standards violation if it were
a GNU project :-(

> 2. Try to keep the bits that need expat "optional", and review whether
>    the code that needs it really benefits all of us, or only a few.

I'll leave this at: I think that the bits we are submitting here are
for the benefit of a bigger slice of GDB's users than you do.  See
Sascha's message on gdb@ this weekend for one example.  And I hope it
will eventually be useful for native users of GDB, at least by making
it easier for us (the maintainers) to add support for new hardware
features that they want to debug.

The XML code has both architecture and target components.  While the
only target to implement it is remote.c, it's easy to keep it optional,
and I'm willing.  But I've already got patches which use this for the
sim/ simulators and for native arm-linux debugging, and I have requests
sitting in my queue to do similar things for two native PowerPC
variants (74xx and e500; and at least the 74xx is a popular native
architecture).

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Add expat to the GDB sources

[Daniel Jacobowitz]

On Mon, Jul 31, 2006 at 08:42:45PM -0400, Daniel Jacobowitz wrote:
> The XML code has both architecture and target components.  While the
> only target to implement it is remote.c, it's easy to keep it optional,
> and I'm willing.  But I've already got patches which use this for the
> sim/ simulators and for native arm-linux debugging, and I have requests
> sitting in my queue to do similar things for two native PowerPC
> variants (74xx and e500; and at least the 74xx is a popular native
> architecture).

... But we could probably find other ways to use the XML data files for
native/sim architectures now that I think about it; we could preprocess
them into C structures and store the C structures in CVS.  That's
actually not too hard.

So, optional can work, at least for now.

-- 
Daniel Jacobowitz
CodeSourcery