From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28440 invoked by alias); 9 Sep 2004 16:05:41 -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 28430 invoked from network); 9 Sep 2004 16:05:39 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 9 Sep 2004 16:05:39 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i89G5YS2023259 for ; Thu, 9 Sep 2004 12:05:39 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i89G5T315074; Thu, 9 Sep 2004 12:05:29 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 698F728D2; Thu, 9 Sep 2004 12:05:25 -0400 (EDT) Message-ID: <41407F45.2090401@gnu.org> Date: Thu, 09 Sep 2004 16:05:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] Deprecate XM_FILE and TM_FILE 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> In-Reply-To: <01c492ff$Blat.v2.2.2$4fec0480@zahav.net.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00146.txt.bz2 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 >>> 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