From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23991 invoked by alias); 7 Dec 2004 14:46:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23942 invoked from network); 7 Dec 2004 14:46:14 -0000 Received: from unknown (209.128.65.135) by sourceware.org with QMTP; 7 Dec 2004 14:46:14 -0000 Received: (qmail 3525 invoked by uid 10); 7 Dec 2004 14:46:13 -0000 Received: (qmail 9746 invoked by uid 500); 7 Dec 2004 14:46:05 -0000 To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: GDB is the GNU project's native debugger References: <419A2E2F.5010602@gnu.org> <419A9BBE.6010000@gnu.org> <419BAB0C.2000607@gnu.org> <41AB9D83.90607@gnu.org> From: Ian Lance Taylor Date: Tue, 07 Dec 2004 14:46:00 -0000 In-Reply-To: <41AB9D83.90607@gnu.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-12/txt/msg00040.txt.bz2 Andrew Cagney writes: > > On your specific issue, I think that async native support would > > require either a flag day or supporting two separate interfaces for > > some time. A flag day is only acceptable if all major architectures > > can be converted simultaneously. Off the cuff I would say that > > supporting two separate interfaces would have to last for at least a > > year. Yes, this is hard. Yes, it leads to more duplicated work. A > > clean and elegant program is a goal, but it is not the only goal. > > I waited a year, and nothing happened. Personally, I would say that after a year you can go ahead and break the code which has not been updated. This doesn't necessarily mean that you should delete it immediately (although of course it can be retrieved from CVS). Just break it. I don't know whether gcc has a notion of "primary platforms," as gcc does. I suppose that it would not be acceptable to break a primary platform. > Is such a rate of change possible if we're required to constantly > schedule flag days, or wait for a year? First, I'll note that if you provide a backward compatibility interface, then the fact that some ports have not been updated does not prevent you from continuing to work. Second, what is your alternative? If your alternative is to cause gdb to not work on many popular platforms, then I suspect that is a false choice. In the long run the effect will be to lose users and developers. That is only acceptable if you are willing and able to be the sole developer of gdb. If not, then you must accomodate other people and their schedules. (Being the only developer may not be absurd. For a couple of years I was essentially the only developer of the binutils--other people contributed target specific ports, but I wrote or rewrote every significant change to the internals. But the binutils are much simpler than gdb.) Ian