[RFA] gdbadmin/ss/gdb_find.sh cleanup

[RFA] gdbadmin/ss/gdb_find.sh cleanup

[Pierre Muller]

    I looked at gdb_find.sh script and discovered
that some of the excluded files do not exist anymore.

  The patch below creates no changes on the ARI output
for me.

The new version of gdb_find.sh is then only:
>>>>>>>>>>>>>>>> `cat gdb_find.sh`
#!/bin/sh

# A find that prunes files that GDB users shouldn't be interested in.

find "$@" \
    -name signals -prune -o \
    -name testsuite -prune -o \
    -name gdbserver -prune -o \
    -name gnulib -prune -o \
    -name rdi-share -prune -o \
    -name osf-share -prune -o \
    -name nlm -prune -o \
    -name '*-stub.c' -prune -o \
    -name '*-exp.c' -prune -o \
    -name 'sh64*' -prune -o \
    -name remote-mips.c -prune -o \
    -type f -name '*.[lyhc]' -print

>>>>>>>>>>>>>>>> end of `cat gdb_find.sh`

Is this patch OK?



  I perfectly understand why *-stub.c patterns are excluded,
*-exp.c patterns should not even appear in a distribution of gdb sources,
but this only also doesn't hurt, I am more curious about
'sh64*' and 'remote-mips.c'
 sh64* covers 
gdb/sh64-tdep.c file
and 
config/sh64 directory.

  Why are those patterns excluded?
Who are the maintainers of these files?
Should we also remove those two lines?

 (I tried removing these two patterns also and I do get 
some more warnings in that case).


Pierre Muller
Pascal language support maintainer for GDB


Commit entry:
	* remove obsolete patterns

$ cvs diff gdb_find.sh
Index: gdb_find.sh
===================================================================
RCS file: /cvs/gdbadmin/ss/gdb_find.sh,v
retrieving revision 1.12
diff -r1.12 gdb_find.sh
15,17d14
<     -name ada-lex.c -prune -o \
<     -name cp-name-parser.c -prune -o \
<     -name stop-gdb.c -prune -o \
19,21d15
<     -name lynx-nat.c -prune -o \
<     -name ppc-bdm.c -prune -o \
<     -name ppc-bdm.c -prune -o \
23,24d16
<     -name remote-sds.c -prune -o \
<     -name remote-sds.c -prune -o \

Pierre@d620-muller ~/ss

Re: [RFA] gdbadmin/ss/gdb_find.sh cleanup

[Joel Brobecker]

>     -name signals -prune -o \

I can't find a "signals" directory. Can you double-check and remove
this line if I'm right? (if it makes sense to you too)

>     -name testsuite -prune -o \
>     -name gdbserver -prune -o \

I wonder if we want to start tracking the gdbserver sources as well.
Just a thought...

>     -name gnulib -prune -o \
>     -name rdi-share -prune -o \

Can't find this directory either...

>     -name remote-mips.c -prune -o \

This file started being excluded in Jan 2005. There's definitely
been some activity on the associated target, so I'm thinking it might
make sense to stop excluding it.

> 'sh64*' and 'remote-mips.c'
>  sh64* covers 
> gdb/sh64-tdep.c file
> and 
> config/sh64 directory.

Strange, I can't find that config/sh64 directory either.

> Why are those patterns excluded?

Here what the CVS log says about the change that introduced the
exclusion:

    revision 1.7
    date: 2004/08/03 13:09:19;  author: cagney;  state: Exp;  lines: +9 -2
    Ignore (hardwired) broken targets.

Since then, it appears that Corinna Vinshen has done some work to
revive the target. So we might again want to remove them from the
exclusion list. To be checked with Corinna?

> <     -name ada-lex.c -prune -o \

DanielJ specifically removed this file from the list. I'm not sure
whether anything changed that would make us change our decision.
This is a generated file - perhaps we should check the source .l
file instead (which I think we do).

> <     -name cp-name-parser.c -prune -o \

Same here. This is a generated file.

> <     -name stop-gdb.c -prune -o \
> 19,21d15
> <     -name lynx-nat.c -prune -o \
> <     -name ppc-bdm.c -prune -o \
> <     -name ppc-bdm.c -prune -o \
> 23,24d16
> <     -name remote-sds.c -prune -o \
> <     -name remote-sds.c -prune -o \

The rest seems OK to me.

-- 
Joel

RE: [RFA] gdbadmin/ss/gdb_find.sh cleanup

[Pierre Muller]

Hi Joel,

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Joel Brobecker
> Envoyé : Wednesday, April 22, 2009 7:57 PM
> À : Pierre Muller
> Cc : gdb-patches@sourceware.org
> Objet : Re: [RFA] gdbadmin/ss/gdb_find.sh cleanup
> 
> >     -name signals -prune -o \
> 
> I can't find a "signals" directory. Can you double-check and remove
> this line if I'm right? (if it makes sense to you too)

  Everything from signals directory seems to have been moved to
common directory by Doug Evans see ChangeLog entry from 2009-03-01.

  I never use -P option for 'cvs up'
and thus have a lot of empty directories lying around!

> >     -name testsuite -prune -o \
> >     -name gdbserver -prune -o \
> 
> I wonder if we want to start tracking the gdbserver sources as well.
> Just a thought...
> 
> >     -name gnulib -prune -o \
> >     -name rdi-share -prune -o \
> 
> Can't find this directory either...
> 
> >     -name remote-mips.c -prune -o \
> 
> This file started being excluded in Jan 2005. There's definitely
> been some activity on the associated target, so I'm thinking it might
> make sense to stop excluding it.
> 
> > 'sh64*' and 'remote-mips.c'
> >  sh64* covers
> > gdb/sh64-tdep.c file
> > and
> > config/sh64 directory.
> Strange, I can't find that config/sh64 directory either.
> 
  Strange because there is a sh64 in gdb/config/CVS/entries
but on the other hand, when I do 'cvs up'
sh64 directory is not listed...

 > > Why are those patterns excluded?
> 
> Here what the CVS log says about the change that introduced the
> exclusion:
> 
>     revision 1.7
>     date: 2004/08/03 13:09:19;  author: cagney;  state: Exp;  lines: +9
> -2
>     Ignore (hardwired) broken targets.
> 
> Since then, it appears that Corinna Vinshen has done some work to
> revive the target. So we might again want to remove them from the
> exclusion list. To be checked with Corinna?
> 
> > <     -name ada-lex.c -prune -o \
> 
> DanielJ specifically removed this file from the list. I'm not sure
> whether anything changed that would make us change our decision.
> This is a generated file - perhaps we should check the source .l
> file instead (which I think we do).
> 
> > <     -name cp-name-parser.c -prune -o \
> 
> Same here. This is a generated file.
> 
> > <     -name stop-gdb.c -prune -o \
> > 19,21d15
> > <     -name lynx-nat.c -prune -o \
> > <     -name ppc-bdm.c -prune -o \
> > <     -name ppc-bdm.c -prune -o \
> > 23,24d16
> > <     -name remote-sds.c -prune -o \
> > <     -name remote-sds.c -prune -o \
> 
> The rest seems OK to me.
> 
> --
> Joel

Below is the new version of gdb_find.sh
that I checked in:
(the diff file is just as big, so I send the new version directly)

Thanks, Joel,

Pierre

$ cat gdb_find.sh
#!/bin/sh

# A find that prunes files that GDB users shouldn't be interested in.

find "$@" \
    -name testsuite -prune -o \
    -name gdbserver -prune -o \
    -name gnulib -prune -o \
    -name osf-share -prune -o \
    -name '*-stub.c' -prune -o \
    -name '*-exp.c' -prune -o \
    -name ada-lex.c -prune -o \
    -name cp-name-parser.c -prune -o \
    -name remote-mips.c -prune -o \
    -type f -name '*.[lyhc]' -print