This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch] Deprecate XM_FILE and TM_FILE
> 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.