From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 601 invoked by alias); 4 Sep 2004 23:20:21 -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 594 invoked from network); 4 Sep 2004 23:20:21 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Sep 2004 23:20:21 -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 i84NKGS2032316 for ; Sat, 4 Sep 2004 19:20:21 -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 i84NKF321508; Sat, 4 Sep 2004 19:20:15 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8629028D2; Sat, 4 Sep 2004 16:37:18 -0400 (EDT) Message-ID: <413A277E.3060700@gnu.org> Date: Sat, 04 Sep 2004 23:20: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> In-Reply-To: <01c4929c$Blat.v2.2.2$3333c200@zahav.net.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-09/txt/msg00080.txt.bz2 > Calling something ``deprecated'' means that it will go away in a > future release. When XM_FILE goes away, xm-go32.h will no longer be > doing its job, and the DJGPP port of GDB will be severely broken. > Therefore, deprecating XM_FILE means you are deprecating the DJGPP > port. Eli, sorry I'm still lost. 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. In fact, thanks to Joel's and MarkK's efforts, we're even ahead of schedule on this one! This is all about preventing new uses of an old mechanism that we're trying to replace, not about deprecating DJGPP. Andrew