From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19915 invoked by alias); 29 Jan 2008 22:41:58 -0000 Received: (qmail 19904 invoked by uid 22791); 29 Jan 2008 22:41:57 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 22:41:27 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 0E47B98151; Tue, 29 Jan 2008 22:41:25 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id E98A69811F; Tue, 29 Jan 2008 22:41:24 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JJz8t-0005UG-SX; Tue, 29 Jan 2008 17:41:23 -0500 Date: Tue, 29 Jan 2008 22:51:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: generic code duplication in Ada files Message-ID: <20080129224123.GA6586@caradoc.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sourceware.org References: <20080129223342.GH16288@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080129223342.GH16288@adacore.com> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00737.txt.bz2 On Tue, Jan 29, 2008 at 02:33:42PM -0800, Joel Brobecker wrote: > Daniel is a bit concerned by the code duplication that is occurring > inside the Ada files (mostly ada-lang.c I believe). Because it's been > the status quo for a while, Daniel didn't reject some patches I recently > submitted, but I certainly heard his comments. Let me try to open up > my mind a bit, and see if that might answer some of those concerns. I came across angrier than I really felt, by the way. I apologize. > We can make happen in the relatively near future. Doing it the other > way will take, I am afraid, quite a bit of time. The cost of compromise > is the semi-duplication that we have now. I can see that it can cause > some maintenance trouble. But I promise in return that I will help > in any way I can: fix the maintenance situations that might arise, > and improve the situation in the long run. This is exactly what I was hoping for. The duplication has been status quo for many years; I don't mind it continuing that way, and once we're in sync you'll have the option of doing restructuring on the FSF tree, getting it right, and then importing it into your local sources - much more palatable. > Typically, my work-flow would involve doing the cleanup in the FSF > tree, get it reviewed and checked in, and then push it to our tree. > That way, I'm sure that any change I make finds its way to the FSF > tree rapidly instead of sitting in our tree first, sometimes forever. Hey, I hadn't even read this paragraph yet and I've already suggested the same thing above! Great! > So, any objection if I took advantage of the current status-quo for > a little while longer? There are no more patches coming except > the ones that are still under review, so we're close to the end > of the tunnel. And that's what I was going to ask. Also great. As long as the file is not growing unboundedly, we're making progress :-) Some of the things in Ada-specific code will be a mess to get into common code, but IMO clearly worthwhile. For instance, a version of symbol lookup which can return more than one symbol. -- Daniel Jacobowitz CodeSourcery