Re: PROPOSAL: removing src/expect

Re: PROPOSAL: removing src/expect

[Michael Elizabeth Chastain]

Hey, I have some good news about Cygwin.

Aaron LaFramboise stepped up and ran the gdb test suite on Cygwin
with the versions of Tcl+Expect+Dejagnu that already ship with Cygwin.
That's TCL 8.4, Expect 5.26, Dejagnu 1.4.2.x.

  http://sources.redhat.com/ml/gdb-testers/2004-q2/msg00159.html

There is one problem with expect on gdb.base/maint.exp.
The problem is intermittent and happens with some runs and not others.
Other than that, the normal Cygwin versions of Tcl+Expect+Dejagnu
work fine for testing gdb.

Michael C

Re: PROPOSAL: removing src/expect

[Christopher Faylor]

On Wed, Jun 16, 2004 at 11:24:21PM -0400, Michael Elizabeth Chastain wrote:
>Hey, I have some good news about Cygwin.
>
>Aaron LaFramboise stepped up and ran the gdb test suite on Cygwin
>with the versions of Tcl+Expect+Dejagnu that already ship with Cygwin.
>That's TCL 8.4, Expect 5.26, Dejagnu 1.4.2.x.
>
>  http://sources.redhat.com/ml/gdb-testers/2004-q2/msg00159.html
>
>There is one problem with expect on gdb.base/maint.exp.
>The problem is intermittent and happens with some runs and not others.
>Other than that, the normal Cygwin versions of Tcl+Expect+Dejagnu
>work fine for testing gdb.

That's not really surprising since these versions all come from
sourceware.

cgf

Re: PROPOSAL: removing src/expect

[Michael Elizabeth Chastain]

Andrew C writes:
> Independent of what happens to this thread, I think GDB (and GCC?) 
> should clarify their test procedures so that they don't direct the 
> developer towards src/expect/.

I agree.

I guess it's my job to write some doco on "how to run the gdb test
suite", and I'll include the steps for downloading tcl + expect +
dejagnu from their public release locations and then building the
things.  I've added this to my to-do list.

One thing I need is a Cygwin + gdb testsuite volunteer.
Anybody out there?

Michael C

Re: PROPOSAL: removing src/expect

[Michael Elizabeth Chastain]

bje> I propose that src/expect be removed from the tree 7 days from now
bje> (2004-06-22 04:00Z).  The version in src is now many years old.  I've
bje> already sent most of the local patches upstream to Don Libes and have
bje> just a handful to go.  Others have suggested leaving in support for an
bje> in-tree Expect and I think that's reasonable.

Okay by me.

Michael C

PROPOSAL: removing src/expect

[Ben Elliston]

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

It seems my initial proposal was just a little bit scary for some, so
I'll suggest something a bit more sedate.

I propose that src/expect be removed from the tree 7 days from now
(2004-06-22 04:00Z).  The version in src is now many years old.  I've
already sent most of the local patches upstream to Don Libes and have
just a handful to go.  Others have suggested leaving in support for an
in-tree Expect and I think that's reasonable.

Any objections?

Ben

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: PROPOSAL: removing src/expect

[Alexandre Oliva]

On Jun 15, 2004, Ben Elliston <bje+dated+1087704905.a97384@air.net.au> wrote:

> I propose that src/expect be removed from the tree 7 days from now

> Any objections?

Err...  Yes, for the same reasons as dejagnu.  It's not bundled with
most of the OSs I used to test, and being able to build expect along
with tcl/tk/etc that were built for GDB/Insight, and dejagnu, that
requires it, was quite handy.  Sure it's old, but it doesn't hurt as
long as it works, no?  And it's not like you're required to check it
out.  I'd rather just leave it there, like dejagnu.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: PROPOSAL: removing src/expect

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Jun 15, 2004, Ben Elliston <bje+dated+1087704905.a97384@air.net.au> wrote:
>
>> I propose that src/expect be removed from the tree 7 days from now
>
>> Any objections?
>
> Err...  Yes, for the same reasons as dejagnu.  It's not bundled with
> most of the OSs I used to test, and being able to build expect along
> with tcl/tk/etc that were built for GDB/Insight, and dejagnu, that
> requires it, was quite handy.  Sure it's old, but it doesn't hurt as
> long as it works, no?  And it's not like you're required to check it
> out.  I'd rather just leave it there, like dejagnu.

And on the other side, I have repeatedly been burnt by systems with
tcl/expect headers installed globally which are incompatible with the
stuff in /cvs/src.  I'd be much happier if tcl/tk/expect were all
three removed from src.

zw

Re: PROPOSAL: removing src/expect

[Alexandre Oliva]

On Jun 15, 2004, Zack Weinberg <zack@codesourcery.com> wrote:

> And on the other side, I have repeatedly been burnt by systems with
> tcl/expect headers installed globally which are incompatible with the
> stuff in /cvs/src.  I'd be much happier if tcl/tk/expect were all
> three removed from src.

My point is that you don't have to check them out if you don't want
to.  If it's just there for those who need it, it can't possibly
hurt.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: PROPOSAL: removing src/expect

[Zack Weinberg]

Alexandre Oliva <aoliva@redhat.com> writes:

> On Jun 15, 2004, Zack Weinberg <zack@codesourcery.com> wrote:
>
>> And on the other side, I have repeatedly been burnt by systems with
>> tcl/expect headers installed globally which are incompatible with the
>> stuff in /cvs/src.  I'd be much happier if tcl/tk/expect were all
>> three removed from src.
>
> My point is that you don't have to check them out if you don't want
> to.  If it's just there for those who need it, it can't possibly
> hurt.

It is surprisingly difficult to check out gdb without getting tcl/tk
as well.  This is probably nothing to do with Ben, though.

zw

Re: PROPOSAL: removing src/expect

[Daniel Jacobowitz]

On Tue, Jun 15, 2004 at 03:29:26PM -0700, Zack Weinberg wrote:
> Alexandre Oliva <aoliva@redhat.com> writes:
> 
> > On Jun 15, 2004, Zack Weinberg <zack@codesourcery.com> wrote:
> >
> >> And on the other side, I have repeatedly been burnt by systems with
> >> tcl/expect headers installed globally which are incompatible with the
> >> stuff in /cvs/src.  I'd be much happier if tcl/tk/expect were all
> >> three removed from src.
> >
> > My point is that you don't have to check them out if you don't want
> > to.  If it's just there for those who need it, it can't possibly
> > hurt.
> 
> It is surprisingly difficult to check out gdb without getting tcl/tk
> as well.  This is probably nothing to do with Ben, though.

That's got nothing to do with getting rid of the in-tree
expect/dejagnu; that has to do with the (long overdue) project to move
Insight out of the GDB directory.  If it were separate, the top-level
rules could be less insistent about ./gdb/ requiring ./tcl/.

-- 
Daniel Jacobowitz

Re: PROPOSAL: removing src/expect

[Andrew Cagney]

> Alexandre Oliva <aoliva@redhat.com> writes:
> 
> 
>>> On Jun 15, 2004, Zack Weinberg <zack@codesourcery.com> wrote:
>>>
>>
>>>>> And on the other side, I have repeatedly been burnt by systems with
>>>>> tcl/expect headers installed globally which are incompatible with the
>>>>> stuff in /cvs/src.  I'd be much happier if tcl/tk/expect were all
>>>>> three removed from src.
>>
>>>
>>> My point is that you don't have to check them out if you don't want
>>> to.  If it's just there for those who need it, it can't possibly
>>> hurt.
> 
> 
> It is surprisingly difficult to check out gdb without getting tcl/tk
> as well.  This is probably nothing to do with Ben, though.

While it's nothing to do with Ben, it's also nothing to do with GDB. 
`cvs -d ... co gdb` doesn't checkout expect/tcl/tk, for that you need to 
explicitly specify gdb+dejagnu.

(Part of the fallout from this change will be dropping the +dejagnu from 
GDB).

Re: PROPOSAL: removing src/expect

[Andreas Schwab]

Andrew Cagney <cagney@gnu.org> writes:

> While it's nothing to do with Ben, it's also nothing to do with GDB. `cvs
> -d ... co gdb` doesn't checkout expect/tcl/tk, for that you need to
> explicitly specify gdb+dejagnu.

And you have to explicitly specify the repository and the destination
directory (if different from the name of the repository).  Except that the
latter does not work with modules that aren't just simple directories.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: PROPOSAL: removing src/expect

[Joe Buck]

On Tue, Jun 15, 2004 at 07:24:24PM -0300, Alexandre Oliva wrote:
> On Jun 15, 2004, Zack Weinberg <zack@codesourcery.com> wrote:
> 
> > And on the other side, I have repeatedly been burnt by systems with
> > tcl/expect headers installed globally which are incompatible with the
> > stuff in /cvs/src.  I'd be much happier if tcl/tk/expect were all
> > three removed from src.
> 
> My point is that you don't have to check them out if you don't want
> to.  If it's just there for those who need it, it can't possibly
> hurt.

The problem is that we then get test reports from two very distinct
versions of dejagnu: an ancient, but hacked up version in the src
tree, as well as currently released versions.  I'd been using a
dejagnu version from src/infrastructure for a long time and getting
lots of bugs on Solaris others weren't seeing, until one day I went out and
got the latest Tcl, Expect, and DejaGNU and suddenly started seeing
almost zero failures.

I understand your issue; you want to quickly get going to test some
obsure platforms.  I think that the way to go about it is to have a
doc pointing to the exact correct versions of Tcl, Expect, and DejaGNU
to use.  We could even have a GARNOME-like facility to download and
build the tarballs, for that matter.

Re: PROPOSAL: removing src/expect

[Alexandre Oliva]

On Jun 15, 2004, Joe Buck <Joe.Buck@synopsys.com> wrote:

> I understand your issue; you want to quickly get going to test some
> obsure platforms.  I think that the way to go about it is to have a
> doc pointing to the exact correct versions of Tcl, Expect, and DejaGNU
> to use.

And why is this better than having the exact correct versions in CVS,
such that people can optionally check it out and use them without a
separate install step?

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: PROPOSAL: removing src/expect

[Ben Elliston]

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

> > I understand your issue; you want to quickly get going to test some
> > obsure platforms.  I think that the way to go about it is to have a
> > doc pointing to the exact correct versions of Tcl, Expect, and DejaGNU
> > to use.
> 
> And why is this better than having the exact correct versions in CVS,
> such that people can optionally check it out and use them without a
> separate install step?

Who is going to do that work?  History says "no one".

Ben

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: PROPOSAL: removing src/expect

[Joel Brobecker]

> Who is going to do that work?  History says "no one".

Actually, I did. I'm now in the process of upgrading all our native
configurations with released versions of tcl+expect+dejagnu (which have
to be fetched from 3 different places, btw). It's no fun, that's for sure.
Fortunately, I'm almost done now, but I found that I'm having a blocking
problem on Tru64 with expect.  Not sure yet if the problem is in expect
or tcl, I'm still debugging, but I feel like I'm wasting time that could
have been used on GDB rather than expect and tcl.

-- 
Joel

Re: PROPOSAL: removing src/expect

[Ben Elliston]

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

> > Who is going to do that work?  History says "no one".
> 
> Actually, I did.

I meant who is going to keep src/expect up to date?  The version
that's there has not been touched since the initial sourceware import
in November 1999.

Ben

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: PROPOSAL: removing src/expect

[Alexandre Oliva]

On Jun 16, 2004, Ben Elliston <bje+dated+1087798498.8ed310@air.net.au> wrote:

> I meant who is going to keep src/expect up to date?  The version
> that's there has not been touched since the initial sourceware import
> in November 1999.

Do we have evidence that it's broken?  If so, we do need an update.
If not, why can't we just leave it at the working state?

Removing it just for the sake of having it gone will gain us nothing,
and will inconvenience those that rely on it.  So, again, what's the
point?

As for who's going to keep it up-to-date, whoever finds that there are
problems in what's in there.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: PROPOSAL: removing src/expect

[Andrew Cagney]

> As for who's going to keep it up-to-date, whoever finds that there are
> problems in what's in there.

Unfortunately, reality rears it's ugly head - what you suggest hasn't 
happened - no one cares enough about src/expect/ to fix it.  I've even 
investigated the effort needed to upgrade expect and decided to walk 
away from the problem - total waste of my time.  Far easier to just use 
the standard expect shipped with the distro's I use.  At least the 
bundled expect works on 64-bit machines like amd64.

Independent of what happens to this thread, I think GDB (and GCC?) 
should clarify their test procedures so that they don't direct the 
developer towards src/expect/.  (Ben, think of this as plan B, if none 
of the GNU projects use/recommend src/expect/ et.al., do they still 
exist? :-)

Andrew

Re: PROPOSAL: removing src/expect

[Joe Buck]

On Wed, Jun 16, 2004 at 04:08:27AM -0300, Alexandre Oliva wrote:
> On Jun 16, 2004, Ben Elliston <bje+dated+1087798498.8ed310@air.net.au> wrote:
> 
> > I meant who is going to keep src/expect up to date?  The version
> > that's there has not been touched since the initial sourceware import
> > in November 1999.
> 
> Do we have evidence that it's broken?  If so, we do need an update.
> If not, why can't we just leave it at the working state?

Yes, last I checked it resulted in failures on Solaris that I don't see
with version 5.40.0 (that is, when I switched from the infrastructure
version of expect to the official one, I suddenly no longer saw lots
of Java failures for Solaris).

Re: PROPOSAL: removing src/expect

[Alexandre Oliva]

On Jun 16, 2004, Joe Buck <Joe.Buck@synopsys.com> wrote:

> Yes, last I checked it resulted in failures on Solaris that I don't see
> with version 5.40.0 (that is, when I switched from the infrastructure
> version of expect to the official one, I suddenly no longer saw lots
> of Java failures for Solaris).

Clearly it's been a while since I last tested uberbaum on 12+
different platforms.  Maybe src/expect just isn't useful any more on
currently-used platforms.  Objections withdrawn.

That said, I'd still like to be able to have check outs of expect,
tcl, tk, dejagnu, etc, and soft-links to them within the uberbaum
tree, and have the just-built trees be used, as if the directories
were in the uberbaum repository.

-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Re: PROPOSAL: removing src/expect

[Ben Elliston]

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

> That said, I'd still like to be able to have check outs of expect,
> tcl, tk, dejagnu, etc, and soft-links to them within the uberbaum
> tree, and have the just-built trees be used, as if the directories
> were in the uberbaum repository.

Sure; that was discussed and I think we all agreed that top-level
support for those directories can stay.  Personally, I think it would
be better if that was removed in the long term, but we can revisit
that on a rainy day (if only it would rain) :-)

So I believe I now have 0 opponents to removing src/expect and, unless
I hear otherwise, will remove it next Tuesday.

Cheers, Ben


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: PROPOSAL: removing src/expect

[Joe Buck]

On Wed, Jun 16, 2004 at 12:33:58AM -0300, Alexandre Oliva wrote:
> On Jun 15, 2004, Joe Buck <Joe.Buck@synopsys.com> wrote:
> 
> > I understand your issue; you want to quickly get going to test some
> > obsure platforms.  I think that the way to go about it is to have a
> > doc pointing to the exact correct versions of Tcl, Expect, and DejaGNU
> > to use.
> 
> And why is this better than having the exact correct versions in CVS,
> such that people can optionally check it out and use them without a
> separate install step?

Up to now, we haven't had the correct version, we've had old versions.

Re: PROPOSAL: removing src/expect

[Ben Elliston]

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

> Err...  Yes, for the same reasons as dejagnu.  It's not bundled with
> most of the OSs I used to test, and being able to build expect along
> with tcl/tk/etc that were built for GDB/Insight, and dejagnu, that
> requires it, was quite handy.  Sure it's old, but it doesn't hurt as
> long as it works, no?  And it's not like you're required to check it
> out.  I'd rather just leave it there, like dejagnu.

In some instances, it is hurting.  A default "src" tree will build and
then use the in-tree expect when running any of the testsuites.  There
have been problems reported that may well have been fixed in the
latest versions of Expect.  However, we're not taking any advantage of
improvements or bug fixes being made by the Expect maintainer(s), thus
creating more hassles and work for ourselves.

Anyway, it's clear that I'm swimming upstream, so I'll let this thread
drop now.

Ben

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]