This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Deprecate XM_FILE and TM_FILE


> Date: Sun, 12 Sep 2004 14:04:47 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: Mark Kettenis <kettenis@gnu.org>, brobecker@gnat.com,
>         gdb-patches@sources.redhat.com
> 
> I think this debate is over the point at which something can be deprecated.

It's about a point where something can be deprecated, and also about
the conditions that should be fulfilled for that.

> For GDB, as soon as we've got the new mechanism up and running - 
> confirming its ok - we're going to draw a line and deprecate the old 
> mechanisms.  We're not going to require that every single detail of 
> every single dependant variant also be addressed.

I don't know about ``we'', but as far as I'm concerned, I cannot
approve a patch that deprecates XM_FILE as long as the 3 defines in
xm-go32.h are not set by an alternative non-deprecated mechanism.

> > We can easily do that (and actually do that) by rejecting patches that
> > use the old mechanism.
> 
> We don't.

Yes, we do.  You can find examples of that in the archives, including
messages by yourself.

> In the past, requests to not use old mechanisms have been [er]
> declined

If such a request is declined, we can reject the patch.  I don't see a
problem here.

Anyway, this is all have been beaten to death in this thread, we are
just reiterating the same issues again and again.  I already suggested
a constructive (IMHO) approach, and I don't have anything new to add
to it.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]