From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26796 invoked by alias); 11 Jul 2008 06:14:04 -0000 Received: (qmail 26784 invoked by uid 22791); 11 Jul 2008 06:14:02 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Jul 2008 06:13:42 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KHBsv-0003Iy-Bb for gdb@sources.redhat.com; Fri, 11 Jul 2008 06:13:37 +0000 Received: from 78.158.192.230 ([78.158.192.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Jul 2008 06:13:37 +0000 Received: from vladimir by 78.158.192.230 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 Jul 2008 06:13:37 +0000 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Move GDB to C++ ? Date: Fri, 11 Jul 2008 06:14:00 -0000 Message-ID: References: <487658F7.1090508@earthlink.net> <18550.27427.430241.185251@gargle.gargle.HOWL> <48767395.7080905@gnu.org> <48767F78.8060806@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.10.9 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00105.txt.bz2 Stan Shebs wrote: > Andrew Cagney wrote: >> The one question I would pose though, is bashing up the current GDB >> code base until it compiles with C++ a reasonable approach? Each time >> C++ has been suggested previously, that has been the proposed path >> forward, and each time it has not moved (I've even tried it my self). >> Perhaps, instead, we should approach this more on a component basis - >> stack, expr, type, proc, debug-info, ..., and convert each chunk in >> turn. And also make use of newer technology such as some of the >> technology that accompanied GOLD. This would suggest working in >> parallel, in a src/gdbxx (gdb++) directory; while this is of course >> longer and harder, I believe we'll see better results. > It's certainly an approach worth thinking about. Presumably the point of > working in a different directory is that the code might be expected to > be broken or nonportable for a period of time, but when that happens you > can run afoul of limited commitment levels, with people only able to > work on gdbxx when they don't have regular gdb tasks. If everyone is > forced into the same straitj^Wsource tree, dealing with mid-transition > brokenness is (usually :-) ) justifiable as part of the job. > > An intermediate strategy might be to enable C++ in the trunk, then do > component replacement on branches. GCC has been having some success with > this; if a branch has something like rewritten symbol handling, then > regular merges will go pretty quickly, and people that don't want to > deal with symbol stuff can continue to work on trunk, knowing that the > branch code will come in when it's ready. I think we should use branches only for really terrible changes that absolutely cannot be done in trunk without making everybody very unhappy. I think most big changes are also fairly mechanical in nature, so are not likely to cause serious instability. - Volodya