Re: [patch] Deprecate XM_FILE and TM_FILE

["Eli Zaretskii" <eliz@gnu.org>]

> Date: Sat, 04 Sep 2004 10:25:47 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: gdb-patches@sources.redhat.com
> 
> This patch deprecates a _mechanism_ not a system.  Doing this makes it 
> explicitly clear that _new_ code _can't_ use it, and that existing code 
> will need to be migrated away from it, over time.

I was reacting to the second meaning (`` that existing code will need
to be migrated away from it, over time'').

>  To that end:
> 
> - we've almost eliminated the xm-*.h files
> - the tm-*.h files are being emptied / deleted

Calling something ``deprecated'' means that it will go away in a
future release.  When XM_FILE goes away, xm-go32.h will no longer be
doing its job, and the DJGPP port of GDB will be severely broken.
Therefore, deprecating XM_FILE means you are deprecating the DJGPP
port.  I don't appreciate this being done without consulting me first.
(I feel the same about the other xm-*.h files being deprecated, but if
their maintainers don't mind, so be it.)

What I would have expected is that if you make a change that has a
potential to break some port, you at the same time commit a change
that fixes the potential damage.  In this case, some alternative way
of getting these macros into the DJGPP port should have been added,
either before or together with the patch that deprecated xm-go32.h.

It is fine not to bother to fix the DJGPP port, and instead leave that
to me, but in that case I'd expect that the offending patch not be
committed until I come up with an alternative solution.

I hope I made myself clear this time.