top-level removal of dejagnu, expect

[Ben Elliston]

> 1. Have you asked EVERY project that uses the src repository?
>    binutils and gdb aren't the only projects.  Why not just remove
>    those directories from the modules file instead?  cgf has already
>    mentioned that src/expect has cygwin-specific code in it.

I have asked the major players and got overwhelming support. Removing
the directories from the modules file is broken, as you know.  It
should be possible to check those files out if they were included in a
past tag (which they were).

As for Expect, the version in src/expect has not been updated since
sourceware was instated last century :-) There are much newer versions
which carry fixes for some of the problems that are being reported.  I
am pushing all patches made since the import to Don Libes and do not
intend to drop any.  I found a couple of patches related to Cygwin.
Many of them were removed by Chris Faylor in 2001, however.

> 2. Our internal repository has a customized dejagnu; it would be
>    convenient for us if support for an in-tree dejagnu were
>    maintained.  Likewise for other developers who may want to (or need
>    to) customize dejagnu for new ports in conjunction with porting the
>    tools.

I stated at the GCC Summit that, as a DejaGnu maintainer, I will be
responsive to urgent bug fixes.  I appreciate that.  Those fixes can
be made available via the Savannah CVS server, or I can push out
maintenance releases as required.  No one felt this was a problem.
Someone said they would be happy to check out the Savannah dejagnu
directory into their uberbaum for "emulation" of the current setup.

> So, I would prefer that support for an in-tree dejagnu were
> retained.  Even if dejagnu and expect were totally wiped from the
> src repository, the toplevel changes would not be needed to support

An in-tree dejagnu is a pain to maintain.  The last six months have
demonstrated this.  I merged the two dejagnu trees at the end of
January and since then, have struggled to keep them in sync.

> that change, so claiming that change is "in preparation for" the
> removal is misleading.  I suggest doing it later, after the dust
> settles, if at all.

No, it is in preparation.  If I didn't make these changes in
preparation, I guarantee that the next night's GDB snapshot would
fail.

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20040610/6f481dc3/attachment.sig>