From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16745 invoked by alias); 29 Jan 2008 22:34:12 -0000 Received: (qmail 16735 invoked by uid 22791); 29 Jan 2008 22:34:11 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 29 Jan 2008 22:33:50 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 4FAEE2A96AF for ; Tue, 29 Jan 2008 17:33:48 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id d-Ienl981NET for ; Tue, 29 Jan 2008 17:33:48 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 0FA982A96A0 for ; Tue, 29 Jan 2008 17:33:48 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 468DEE7ACB; Tue, 29 Jan 2008 14:33:42 -0800 (PST) Date: Tue, 29 Jan 2008 22:41:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: generic code duplication in Ada files Message-ID: <20080129223342.GH16288@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i 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/msg00736.txt.bz2 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 don't want to force these changes onto the GDB project if they are going to cause disatisfaction. I'm trying to find what's best given the current situation. It's going to be a while before we start unifying this code back together, but this is definitely something we also want to do. We could work on making these cleanups in our tree until we're ready to reveal an improved version of the Ada support. But this cleanup will touch what I call the core files, and I like to have feedback when I make these types of changes, just to make sure that I'm going in a direction that satisfies everyone. Sometimes, what's obvious to me can be strange to others. In the past, I've asked for feedback for changes that I could then not contribute because the changes were based on some code that was not perfect yet. I felt uncomfortable because I was getting advice and not giving back in return. This time, I want things to be different. I want Ada enthusiasts to be able to download the debugger from the FSF and have an enjoyable experience using it. 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. In the meantime, having the AdaCore sources and the FSF sources be as close as possible allow us to: - Effectively test on a regular basis the FSF debugger against our testsuite, which contains quite a few testcases that we can't contribute. - Work on the cleanup in one debugger without having to worry about the other one. 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. 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. -- Joel