From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20679 invoked by alias); 9 Sep 2004 19:31:10 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 20672 invoked from network); 9 Sep 2004 19:31:09 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 9 Sep 2004 19:31:09 -0000 Received: from zaretski ([80.230.141.72]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CNA56614 (AUTH halo1); Thu, 9 Sep 2004 22:31:05 +0300 (IDT) Date: Thu, 09 Sep 2004 19:31:00 -0000 From: "Eli Zaretskii" To: Andrew Cagney Message-ID: <01c496a3$Blat.v2.2.2$8948c5e0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: gdb-patches@sources.redhat.com In-reply-to: <41407F45.2090401@gnu.org> (message from Andrew Cagney on Thu, 09 Sep 2004 12:05:25 -0400) Subject: Re: [patch] Deprecate XM_FILE and TM_FILE Reply-to: Eli Zaretskii References: <41376681.4050203@gnu.org> <01c4912b$Blat.v2.2.2$2bea1980@zahav.net.il> <413898FB.7080502@gnu.org> <01c49276$Blat.v2.2.2$c81daa00@zahav.net.il> <4139D06B.5060902@gnu.org> <01c4929c$Blat.v2.2.2$3333c200@zahav.net.il> <413A277E.3060700@gnu.org> <01c492ff$Blat.v2.2.2$4fec0480@zahav.net.il> <41407F45.2090401@gnu.org> X-SW-Source: 2004-09/txt/msg00151.txt.bz2 > Date: Thu, 09 Sep 2004 12:05:25 -0400 > From: Andrew Cagney > 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.