Re: [patch] Deprecate XM_FILE and TM_FILE

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

> Date: Thu, 09 Sep 2004 12:05:25 -0400
> From: Andrew Cagney <cagney@gnu.org>
> Cc: gdb-patches@sources.redhat.com
> 
> - the subject line specified `PATCH'

Yes.  Many patches that were committed lately said "PATCH" in the
Subject and then "Committed" in the body.  That's what probably fooled
me, for which I'm nevertheless sorry.

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

Deprecating XM_FILE means it will be deleted in the next major
release.  So I'm complaining now to prevent the more-or-less automatic
deletion of anything that matches the regexp "deprecated.*"
(case-insensitively) in the near future, when it would be too late to
complain.

> 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

Yes.  And I also request that the replacement for these xm-*.h
definitions be in place _before_ we deprecate XM_FILE, because in my
book, a feature that is being actively used cannot be deprecated.

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

So let's do it before XM_FILE is deprecated.

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

I don't mind doing the ``dirty work'' myself, if you will wait with
the XM_FILE deprecation until I find the time to do it.  If you cannot
wait, I think it is only natural that you do that job as part of the
patch that deprecates XM_FILE.