This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [commit] Deprecate remaining STREQ uses
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Mon, 1 Dec 2003 14:17:31 -0500
- Subject: Re: [commit] Deprecate remaining STREQ uses
- References: <ufzgee29u.fsf@elta.co.il> <3FC234C0.1000500@gnu.org> <20031124165047.GA2227@nevyn.them.org> <1031124182547.ZM9776@localhost.localdomain> <3FC26407.9000704@gnu.org> <1031125000932.ZM11256@localhost.localdomain> <3FC60A75.8090803@gnu.org> <9178-Thu27Nov2003192422+0200-eliz@elta.co.il> <3FCB6275.2070403@gnu.org> <6654-Mon01Dec2003210731+0200-eliz@elta.co.il>
On Mon, Dec 01, 2003 at 09:07:32PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 01 Dec 2003 10:47:01 -0500
> > From: Andrew Cagney <cagney@gnu.org>
> > >
> > > But that's precisely why we have the patch review and approval
> > > procedure, right? Maintainers who approve patches are supposed to
> > > prevent code that uses deprecated machinery from being added.
> >
> > Very true. Explicit deprecation is a tool for making that part of the
> > maintainer and contributor task far easier. Instead of wasting time
> > trying to track and find all the things being eliminated, the
> > contributor and reviewer can simply keep an eye out for deprecated in
> > their patches
>
> I'm not convinced that detecting STREQ is harder than detecting
> DEPRECATED_STREQ.
Neither am I... Andrew, how would you feel about a central (in the
source tree) list of deprecated objects instead?
Personally, I'd like for the ARI scripts to be in the source tree too.
$ make
init.c updated.
gcc -o gdb .....
$ make ari
sh $(srcdir)/gdb_ari.sh $(srcdir) ari-output.txt
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer