From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22649 invoked by alias); 4 Sep 2004 16:28:12 -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 22639 invoked from network); 4 Sep 2004 16:28:11 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 4 Sep 2004 16:28:11 -0000 Received: from zaretski ([80.230.148.243]) by legolas.inter.net.il (MOS 3.5.3-GR) with ESMTP id CLT45511 (AUTH halo1); Sat, 4 Sep 2004 19:28:07 +0300 (IDT) Date: Sat, 04 Sep 2004 16:28:00 -0000 From: "Eli Zaretskii" To: Andrew Cagney Message-ID: <01c4929c$Blat.v2.2.2$3333c200@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: gdb-patches@sources.redhat.com In-reply-to: <4139D06B.5060902@gnu.org> (message from Andrew Cagney on Sat, 04 Sep 2004 10:25:47 -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> X-SW-Source: 2004-09/txt/msg00078.txt.bz2 > Date: Sat, 04 Sep 2004 10:25:47 -0400 > From: Andrew Cagney > Cc: gdb-patches@sources.redhat.com > > This patch deprecates a _mechanism_ not a system. Doing this makes it > explicitly clear that _new_ code _can't_ use it, and that existing code > will need to be migrated away from it, over time. I was reacting to the second meaning (`` that existing code will need to be migrated away from it, over time''). > To that end: > > - we've almost eliminated the xm-*.h files > - the tm-*.h files are being emptied / deleted 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. I don't appreciate this being done without consulting me first. (I feel the same about the other xm-*.h files being deprecated, but if their maintainers don't mind, so be it.) 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. In this case, some alternative way of getting these macros into the DJGPP port should have been added, either before or together with the patch that deprecated xm-go32.h. It is fine not to bother to fix the DJGPP port, and instead leave that to me, but in that case I'd expect that the offending patch not be committed until I come up with an alternative solution. I hope I made myself clear this time.