Re: [patch] Deprecate XM_FILE and TM_FILE

[Andrew Cagney <cagney at gnu dot org>]

Earlier you wrote:

> 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.

Just so that we're on the same page, my change has not been committed:
- per last flame war, deprecations are given a week
- I clearly stated ``I'll _look_ to commit this in a week,''
- a check of CVS shows no such commit
however:
- the subject line specified `PATCH'
While we've all come to learn that the word PATCH in the subject line 
conveys no meaning (committed? rfa? rfc? ...?), I should have remembered 
to avoid it - brain fart.

First, lets just clarify something>>> Date: Sat, 04 Sep 2004 16:37:18 -0400
> > > From: Andrew Cagney <cagney@gnu.org>
> > > Cc: gdb-patches@sources.redhat.com
> > >
> > > Here, the xm-go32.h file will have been removed before the XM_FILE 
> > > mechanism goes away (if it hasn't we've both seriously fallen down on 
> > > the job :-) and therefore, DJGPP won't be broken.
>
>
> Who is going to replace xm-go32.h with something that will preserve
> the functionality?  And why isn't that something checked in before
> XM_FILE is deprecated?

We've the following mechanisms:

	*.mh:XM_FILE
	#define GDBINIT_FILENAME
	#define CRLF_SOURCE_FILES
	#define DIRNAME_SEPARATOR

Here I'm ``disapproving'' the mechanism XM_FILE and have said nothing of 
GDBINIT_FILENAME et.al.

Now if I were to try to either:

- deprecate or delete GDBINIT_FILENAME without a replacement
- delete XM_FILE without eliminating DJGPP's dependence

then you'd have strong grounds for complaint.  Fortunatly, I've been 
very careful to not do this.

So to back you your original question.  I think you're asking who will 
cut the code necessary to acheive each of:

- eliminate/replace GDBINIT_FILENAME from xm-*.h
- eliminate/replace CRLF_SOURCE_FILES from xm-*.h
- eliminate/replace DIRNAME_SEPARATOR from xm-*.h

as they block the elimination (not deprecation) of XM_FILE.

short answer: I don't know.

long answer: It doesn't matter.
What matters is that it gets done.  To that end we're both ultimatly 
responsble for ensuring that it does.

Having said that, I think we can assume that it will end up being me 
that does the dirty work.

Andrew