Trimming the CVS "gdb" module

Trimming the CVS "gdb" module

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

Following tries to close a number of random discussions that noticed 
that the GDB module contains stuff that is no longer applicable.

The attached modifies GDB's "gdb" CVS module trimming it back to what is 
currently relevant.  It drops mmalloc/ (not used), cgen/cpu/ (moved to 
cpu/), intl (use installed), and utils/ (not used).

It also adds the module old-gdb which retains all the old directories 
and hence can be used to check out old gdb versions (although "gdb" will 
be sufficient for most needs).

I'll look to commit this in a week, this needs to be closed before 6.3 
is branched.

Andrew


[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1481 bytes --]

? diffs
Index: modules
===================================================================
RCS file: /cvs/src/CVSROOT/modules,v
retrieving revision 1.56
diff -p -u -r1.56 modules
--- modules	30 Mar 2004 01:35:57 -0000	1.56
+++ modules	6 Oct 2004 16:36:49 -0000
@@ -128,14 +128,22 @@ sim		-a naked-sim naked-bfd naked-opcode
 		naked-libiberty naked-mmalloc naked-include \
 		src-support naked-intl
 
-naked-gdb-guifull -a src/gdb
-naked-gdb	-a !src/gdb/gdbtk !src/gdb/testsuite/gdb.gdbtk src/gdb
-gdb-support	-a naked-texinfo naked-bfd naked-opcodes \
+# OLD-GDB contains everything that ever was in GDB.  It can be used to
+# check out out old GDB branches and as an approximation for an old
+# mainline.
+old-gdb		-a !src/gdb/gdbtk !src/gdb/testsuite/gdb.gdbtk src/gdb \
+		naked-texinfo naked-bfd naked-opcodes \
 		naked-readline naked-libiberty naked-mmalloc naked-include \
 		naked-sim naked-utils src-support naked-intl naked-cpu \
-		src/cgen/cpu \
-		src/djunpack.bat
+		src/cgen/cpu src/djunpack.bat
 
+naked-gdb-guifull -a src/gdb
+naked-gdb	-a !src/gdb/gdbtk !src/gdb/testsuite/gdb.gdbtk src/gdb
+gdb-support	-a naked-texinfo naked-bfd naked-opcodes \
+		naked-readline naked-libiberty naked-include \
+		naked-sim naked-utils naked-cpu src/djunpack.bat \
+		src-support
+# Module reflecting active development.
 gdb		-a naked-gdb gdb-support
 gdb+dejagnu	-a gdb naked-dejagnu naked-expect naked-tcl
 gdb+binutils	-a gdb naked-binutils naked-gas naked-gprof naked-ld

Re: Trimming the CVS "gdb" module

[Eli Zaretskii]

> Date: Wed, 06 Oct 2004 12:44:47 -0400
> From: Andrew Cagney <cagney@gnu.org>
> 
> The attached modifies GDB's "gdb" CVS module trimming it back to what is 
> currently relevant.  It drops mmalloc/ (not used), cgen/cpu/ (moved to 
> cpu/), intl (use installed), and utils/ (not used).

I have concerns about the `intl' part.  Where, if anywhere at all,
will GDB distributions keep the stuff that is currently in `intl'?
AFAIR, GNU projects that support l10n bring this stuff with them, they
do not rely on the installed gettext facilities as the sole solution.
Are we going to create a new directory `gdb/intl' and import files
there from the GNU gettext CVS tree, or will we do somthing else?

Re: Trimming the CVS "gdb" module

[Andrew Cagney]

>>> Date: Wed, 06 Oct 2004 12:44:47 -0400
>>> From: Andrew Cagney <cagney@gnu.org>
>>> 
>>> The attached modifies GDB's "gdb" CVS module trimming it back to what is 
>>> currently relevant.  It drops mmalloc/ (not used), cgen/cpu/ (moved to 
>>> cpu/), intl (use installed), and utils/ (not used).

For intl, this came up here:
http://sources.redhat.com/ml/gdb-patches/2004-07/msg00442.html
http://sources.redhat.com/ml/gdb-patches/2004-08/msg00154.html

> I have concerns about the `intl' part.  Where, if anywhere at all,
> will GDB distributions keep the stuff that is currently in `intl'?
> AFAIR, GNU projects that support l10n bring this stuff with them, they
> do not rely on the installed gettext facilities as the sole solution.
> Are we going to create a new directory `gdb/intl' and import files
> there from the GNU gettext CVS tree, or will we do somthing else?

On GNU systems, intl is already available and installed and GDB's 
configuration is set up to use it (similar for my "Free" NetBSD system).

Andrew

Re: Trimming the CVS "gdb" module

[Eli Zaretskii]

> Date: Tue, 12 Oct 2004 15:47:58 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: gdb@sources.redhat.com
> 
> > I have concerns about the `intl' part.  Where, if anywhere at all,
> > will GDB distributions keep the stuff that is currently in `intl'?
> > AFAIR, GNU projects that support l10n bring this stuff with them, they
> > do not rely on the installed gettext facilities as the sole solution.
> > Are we going to create a new directory `gdb/intl' and import files
> > there from the GNU gettext CVS tree, or will we do somthing else?
> 
> On GNU systems, intl is already available and installed and GDB's 
> configuration is set up to use it (similar for my "Free" NetBSD system).

I understand (from the URLs of past threads) that GDB will not come
with intl stuff, and so users of systems where there's no intl are on
their own.  I don't really understand why other GNU projects can come
with intl and be built with it while GDB cannot, but if people here
are okay with leaving this unfixed, so be it.

Re: Trimming the CVS "gdb" module

[Mark Kettenis]

   Date: Wed, 13 Oct 2004 06:53:40 +0200
   From: "Eli Zaretskii" <eliz@gnu.org>

   > Date: Tue, 12 Oct 2004 15:47:58 -0400
   > From: Andrew Cagney <cagney@gnu.org>
   > Cc: gdb@sources.redhat.com
   > 
   > On GNU systems, intl is already available and installed and GDB's 
   > configuration is set up to use it (similar for my "Free" NetBSD system).

   I understand (from the URLs of past threads) that GDB will not come
   with intl stuff, and so users of systems where there's no intl are on
   their own.  I don't really understand why other GNU projects can come
   with intl and be built with it while GDB cannot, but if people here
   are okay with leaving this unfixed, so be it.

Many of the other GNU projects are broken on systems that don't come
with intl because the intl that comes bundled with the project doesn't
build.

Mark

Re: Trimming the CVS "gdb" module

[Eli Zaretskii]

> Date: Wed, 13 Oct 2004 17:35:08 +0200 (CEST)
> From: Mark Kettenis <kettenis@gnu.org>
> CC: cagney@gnu.org, gdb@sources.redhat.com
> 
> Many of the other GNU projects are broken on systems that don't come
> with intl because the intl that comes bundled with the project doesn't
> build.

Perhaps that's true, but we don't have to learn from the projects that
have this problem.  Let's learn from those which did solve this
successfully.

In any case, the threads that Andrew pointed to were about replacing a
100% broken feature with one that works on some systems.  Now it
sounds like we are going to decide that the temporary solution is the
one to stay for good.  Let's at least record somewhere that there's a
problem here that we hope one day to solve.

Re: Trimming the CVS "gdb" module

[Andrew Cagney]

Andrew Cagney wrote:
> Following tries to close a number of random discussions that noticed 
> that the GDB module contains stuff that is no longer applicable.
> 
> The attached modifies GDB's "gdb" CVS module trimming it back to what is 
> currently relevant.  It drops mmalloc/ (not used), cgen/cpu/ (moved to 
> cpu/), intl (use installed), and utils/ (not used).
> 
> It also adds the module old-gdb which retains all the old directories 
> and hence can be used to check out old gdb versions (although "gdb" will 
> be sufficient for most needs).
> 
> I'll look to commit this in a week, this needs to be closed before 6.3 
> is branched.
> 
> Andrew

This is in (I need it to create the backdated branch).

Andrew

Re: Trimming the CVS "gdb" module

[Andrew Cagney]

Eli Zaretskii wrote:

> Perhaps that's true, but we don't have to learn from the projects that
> have this problem.  Let's learn from those which did solve this
> successfully.
> 
> In any case, the threads that Andrew pointed to were about replacing a
> 100% broken feature with one that works on some systems.  Now it
> sounds like we are going to decide that the temporary solution is the
> one to stay for good.  Let's at least record somewhere that there's a
> problem here that we hope one day to solve.

Can you describe the problem we're expecting to solve?

Andrew

Re: Trimming the CVS "gdb" module

[Eli Zaretskii]

> Date: Tue, 19 Oct 2004 10:18:02 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: Mark Kettenis <kettenis@gnu.org>, gdb@sources.redhat.com
> 
> Can you describe the problem we're expecting to solve?

The problem whereby it's impossible to have i18n support in GDB unless
there's already gettext installed on the end-user system.

Re: Trimming the CVS "gdb" module

[Mark Kettenis]

   Date: Tue, 19 Oct 2004 22:08:24 +0200
   From: "Eli Zaretskii" <eliz@gnu.org>

   The problem whereby it's impossible to have i18n support in GDB unless
   there's already gettext installed on the end-user system.

Indeed, but how is this different from only having TUI support if
there's already a curses library installed on the end-user system?

Mark

Re: Trimming the CVS "gdb" module

[Eli Zaretskii]

> Date: Tue, 19 Oct 2004 22:22:45 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: cagney@gnu.org, gdb@sources.redhat.com
> 
> how is this different from only having TUI support if there's
> already a curses library installed on the end-user system?

It's different because the technology for bringing gettext with a
package's tarball and building it as part of the package build is
known and used by other GNU packages.  By contrast, no GNU package
known to me comes with a replacement for curses (and curses-like
libraries will not work on non-Posix systems anyway, since AFAIK they
rely heavily on Unix-style terminal driver features).

Re: Trimming the CVS "gdb" module

[Andrew Cagney]

Eli Zaretskii wrote:
>>Date: Tue, 19 Oct 2004 10:18:02 -0400
>>From: Andrew Cagney <cagney@gnu.org>
>>Cc: Mark Kettenis <kettenis@gnu.org>, gdb@sources.redhat.com
>>
>>Can you describe the problem we're expecting to solve?
> 
> 
> The problem whereby it's impossible to have i18n support in GDB unless
> there's already gettext installed on the end-user system.

Are there any current GNU systems that have this problem?
Are there any current non-GNU systems have this problem?

Do the circumstances that lead to intl/ being bundled with all those 
other packages actually still exist?

Andrew

PS: Up to and including 6.2, GDB didn't even need intl/ yet it was 
bundling it.  It was an artifact inherited from the Cygnus tree.

Re: Trimming the CVS "gdb" module

[Eli Zaretskii]

> Date: Tue, 19 Oct 2004 18:54:40 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: kettenis@gnu.org, gdb@sources.redhat.com
> 
> Are there any current GNU systems that have this problem?

I don't know.  I was talking about non-GNU systems, since you said
that GNU systems always come with gettext.

> Are there any current non-GNU systems have this problem?

Any non-GNU system where there's no gettext installed would be
affected.  All the Unix and Windows boxes I'm working on are like
that.

> PS: Up to and including 6.2, GDB didn't even need intl/ yet it was 
> bundling it.  It was an artifact inherited from the Cygnus tree.

Like I said, I'm not opposed to what you did if we intend to add it
back at some future date, when GDB will support gettext and message
catalogs.  What worries me is that it sounds like we intend to remove
the i18n stuff for good.

Re: Trimming the CVS "gdb" module

[Andrew Cagney]

Eli Zaretskii wrote:

> Like I said, I'm not opposed to what you did if we intend to add it
> back at some future date, when GDB will support gettext and message
> catalogs.  What worries me is that it sounds like we intend to remove
> the i18n stuff for good.

Um, GDB supports gettext and message catalogs today.  What we're lacking is:
- markups (only one file's been done)
- translations (kind of predicated on the first option)
- fixes to i18n unfriendly code (using the translations should flush 
these out)
Even on _current_ non-GNU systems that don't bundle intl/ it's 
supported, the user just needs to install intl/ first.  Alternativily, 
someone, could step forward and upgrade/maintain src/intl/.

Andrew

Re: Trimming the CVS "gdb" module

[Eli Zaretskii]

> Date: Wed, 20 Oct 2004 11:11:10 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: kettenis@gnu.org, gdb@sources.redhat.com
> 
> Eli Zaretskii wrote:
> 
> > Like I said, I'm not opposed to what you did if we intend to add it
> > back at some future date, when GDB will support gettext and message
> > catalogs.  What worries me is that it sounds like we intend to remove
> > the i18n stuff for good.
> 
> Um, GDB supports gettext and message catalogs today.

Unfortunate wording on my part: I should have said ``when GDB will
_have_ message catalogs''.

Anyway, that's not the issue

> Even on _current_ non-GNU systems that don't bundle intl/ it's 
> supported, the user just needs to install intl/ first.

That's exactly what worries me: other packages come with `intl' that
gets built as part of "make", unless you disable that through a
configure-time switch.

> Alternativily, someone, could step forward and upgrade/maintain
> src/intl/.

Can't we copycat what Binutils does?  IIRC, it comes with an `intl'
directory under `binutils-X.Y.Z', or at least it used to last time I
looked.

Re: Trimming the CVS "gdb" module

[Daniel Jacobowitz]

On Wed, Oct 20, 2004 at 08:26:44PM +0200, Eli Zaretskii wrote:
> > Alternativily, someone, could step forward and upgrade/maintain
> > src/intl/.
> 
> Can't we copycat what Binutils does?  IIRC, it comes with an `intl'
> directory under `binutils-X.Y.Z', or at least it used to last time I
> looked.

Yes, the very same copy we just removed from the GDB distribution.
No one has felt motivated enough to update it lately.  GCC has an
updated copy we could pull.

-- 
Daniel Jacobowitz

Re: Trimming the CVS "gdb" module

[Eli Zaretskii]

> Date: Wed, 20 Oct 2004 18:21:13 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Andrew Cagney <cagney@gnu.org>, kettenis@gnu.org,
> 	gdb@sources.redhat.com
> 
> > Can't we copycat what Binutils does?  IIRC, it comes with an `intl'
> > directory under `binutils-X.Y.Z', or at least it used to last time I
> > looked.
> 
> Yes, the very same copy we just removed from the GDB distribution.
> No one has felt motivated enough to update it lately.  GCC has an
> updated copy we could pull.

I didn't mean just the directory contents, I meant primarily the
configure- and build-time machinery that gets gettext to build and be
installed together with GDB, so that the installed GDB could use it.

Re: Trimming the CVS "gdb" module

[Daniel Jacobowitz]

On Thu, Oct 21, 2004 at 07:05:33AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 20 Oct 2004 18:21:13 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Andrew Cagney <cagney@gnu.org>, kettenis@gnu.org,
> > 	gdb@sources.redhat.com
> > 
> > > Can't we copycat what Binutils does?  IIRC, it comes with an `intl'
> > > directory under `binutils-X.Y.Z', or at least it used to last time I
> > > looked.
> > 
> > Yes, the very same copy we just removed from the GDB distribution.
> > No one has felt motivated enough to update it lately.  GCC has an
> > updated copy we could pull.
> 
> I didn't mean just the directory contents, I meant primarily the
> configure- and build-time machinery that gets gettext to build and be
> installed together with GDB, so that the installed GDB could use it.

Yes, that's what I meant also.  None of that lives under gdb/; it's all
in the top level or within intl/.

-- 
Daniel Jacobowitz