PATCH Makefile.in

PATCH Makefile.in

[Ben Elliston]

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

There is no longer an in-tree version of DejaGnu in src/dejagnu.  This
patch just keeps the gdb Makefile up to date.  Okay for mainline?

2005-06-30  Ben Elliston  <bje@gnu.org>

        * Makefile.in (RUNTEST): Set to runtest.

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.738
diff -u -p -r1.738 Makefile.in
--- Makefile.in 25 Jun 2005 11:54:29 -0000      1.738
+++ Makefile.in 29 Jun 2005 20:36:13 -0000
@@ -389,10 +389,7 @@ LINTFLAGS= $(GDB_CFLAGS) $(OPCODES_CFLAG
        $(BFD_CFLAGS) $(INCLUDE_CFLAGS) \
        $(INTL_CFLAGS)
 
-RUNTEST = `if [ -f $${rootsrc}/../dejagnu/runtest ] ; then \
-               echo $${rootsrc}/../dejagnu/runtest ; else echo runtest; \
-          fi`
-
+RUNTEST = runtest
 RUNTESTFLAGS=
 
 # This is ser-unix.o for any system which supports a v7/BSD/SYSV/POSIX

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

Re: PATCH Makefile.in

[Alexandre Oliva]

On Jun 29, 2005, Ben Elliston <bje+dated+1120509497.910ead@air.net.au> wrote:

> There is no longer an in-tree version of DejaGnu in src/dejagnu.  This
> patch just keeps the gdb Makefile up to date.

Not really.  It has no advantage whatsoever for those who no longer
have dejagnu/runtest in their build trees, but it breaks for those who
happen to do.  I don't think it's enough of a clean-up to be worth
the potential hassle.

-- 
Alexandre Oliva         http://www.lsd.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: PATCH Makefile.in

[Daniel Jacobowitz]

On Sat, Jul 02, 2005 at 02:53:20PM -0300, Alexandre Oliva wrote:
> On Jun 29, 2005, Ben Elliston <bje+dated+1120509497.910ead@air.net.au> wrote:
> 
> > There is no longer an in-tree version of DejaGnu in src/dejagnu.  This
> > patch just keeps the gdb Makefile up to date.
> 
> Not really.  It has no advantage whatsoever for those who no longer
> have dejagnu/runtest in their build trees, but it breaks for those who
> happen to do.  I don't think it's enough of a clean-up to be worth
> the potential hassle.

I don't want to carry this baggage around forever.  We already rely on
plenty of installed tools; I think it's long past time to add expect
and dejagnu to the list.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH Makefile.in

[Alexandre Oliva]

On Jul  3, 2005, Daniel Jacobowitz <drow@false.org> wrote:

> On Sat, Jul 02, 2005 at 02:53:20PM -0300, Alexandre Oliva wrote:
>> On Jun 29, 2005, Ben Elliston <bje+dated+1120509497.910ead@air.net.au> wrote:
>> 
>> > There is no longer an in-tree version of DejaGnu in src/dejagnu.  This
>> > patch just keeps the gdb Makefile up to date.
>> 
>> Not really.  It has no advantage whatsoever for those who no longer
>> have dejagnu/runtest in their build trees, but it breaks for those who
>> happen to do.  I don't think it's enough of a clean-up to be worth
>> the potential hassle.

> I don't want to carry this baggage around forever.  We already rely on
> plenty of installed tools; I think it's long past time to add expect
> and dejagnu to the list.

This is an argument for the removal of dejagnu and expect from the
tree, which I agree with.  It's the one-line change in the test to
decide which RUNTEST to use that I'm opposing.  I can't imagine such a
line is too much baggage to carry around.  If you think so, well...  I
guess I'll just shut up and wait until your next ports require changes
in dejagnu.

-- 
Alexandre Oliva         http://www.lsd.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: PATCH Makefile.in

[Daniel Jacobowitz]

On Mon, Jul 04, 2005 at 10:46:35AM -0300, Alexandre Oliva wrote:
> This is an argument for the removal of dejagnu and expect from the
> tree, which I agree with.  It's the one-line change in the test to
> decide which RUNTEST to use that I'm opposing.  I can't imagine such a
> line is too much baggage to carry around.  If you think so, well...  I
> guess I'll just shut up and wait until your next ports require changes
> in dejagnu.

I keep a local copy of dejagnu in my PATH.  I've been doing this for
years (and yes, I do deal with two ports that require changes in
dejagnu).  I find this way much more convenient...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH Makefile.in

[Alexandre Oliva]

On Jul  4, 2005, Daniel Jacobowitz <drow@false.org> wrote:

> On Mon, Jul 04, 2005 at 10:46:35AM -0300, Alexandre Oliva wrote:
>> This is an argument for the removal of dejagnu and expect from the
>> tree, which I agree with.  It's the one-line change in the test to
>> decide which RUNTEST to use that I'm opposing.  I can't imagine such a
>> line is too much baggage to carry around.  If you think so, well...  I
>> guess I'll just shut up and wait until your next ports require changes
>> in dejagnu.

> I keep a local copy of dejagnu in my PATH.  I've been doing this for
> years (and yes, I do deal with two ports that require changes in
> dejagnu).  I find this way much more convenient...

But not as safe.  E.g., I don't want net GCC test runs to be affected
by my local changes to dejagnu required by an ongoing port.

-- 
Alexandre Oliva         http://www.lsd.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: PATCH Makefile.in

[Daniel Jacobowitz]

On Tue, Jul 05, 2005 at 02:33:12PM -0300, Alexandre Oliva wrote:
> On Jul  4, 2005, Daniel Jacobowitz <drow@false.org> wrote:
> 
> > On Mon, Jul 04, 2005 at 10:46:35AM -0300, Alexandre Oliva wrote:
> >> This is an argument for the removal of dejagnu and expect from the
> >> tree, which I agree with.  It's the one-line change in the test to
> >> decide which RUNTEST to use that I'm opposing.  I can't imagine such a
> >> line is too much baggage to carry around.  If you think so, well...  I
> >> guess I'll just shut up and wait until your next ports require changes
> >> in dejagnu.
> 
> > I keep a local copy of dejagnu in my PATH.  I've been doing this for
> > years (and yes, I do deal with two ports that require changes in
> > dejagnu).  I find this way much more convenient...
> 
> But not as safe.  E.g., I don't want net GCC test runs to be affected
> by my local changes to dejagnu required by an ongoing port.

It's obvious that we don't agree.  But does anyone besides yourself
still see value in this?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH Makefile.in

[Alexandre Oliva]

On Jul  5, 2005, Daniel Jacobowitz <drow@false.org> wrote:

> On Tue, Jul 05, 2005 at 02:33:12PM -0300, Alexandre Oliva wrote:
>> On Jul  4, 2005, Daniel Jacobowitz <drow@false.org> wrote:
>> 
>> > On Mon, Jul 04, 2005 at 10:46:35AM -0300, Alexandre Oliva wrote:
>> >> This is an argument for the removal of dejagnu and expect from the
>> >> tree, which I agree with.  It's the one-line change in the test to
>> >> decide which RUNTEST to use that I'm opposing.  I can't imagine such a
>> >> line is too much baggage to carry around.  If you think so, well...  I
>> >> guess I'll just shut up and wait until your next ports require changes
>> >> in dejagnu.
>> 
>> > I keep a local copy of dejagnu in my PATH.  I've been doing this for
>> > years (and yes, I do deal with two ports that require changes in
>> > dejagnu).  I find this way much more convenient...
>> 
>> But not as safe.  E.g., I don't want net GCC test runs to be affected
>> by my local changes to dejagnu required by an ongoing port.

> It's obvious that we don't agree.  But does anyone besides yourself
> still see value in this?

I guess not, so I'll withdraw my objection, since it looks like I'm by
myself, and I don't want to be the one on the way of, erhm, progress?
:-)

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