From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26235 invoked by alias); 19 Jun 2009 16:56:42 -0000 Received: (qmail 26226 invoked by uid 22791); 19 Jun 2009 16:56:41 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from cam-admin0.cambridge.arm.com (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Jun 2009 16:56:34 +0000 Received: from cam-owa2.Emea.Arm.com (cam-owa2.emea.arm.com [10.1.105.18]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id n5JGrxZm021165; Fri, 19 Jun 2009 17:53:59 +0100 (BST) Received: from [10.1.129.13] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 17:56:28 +0100 Subject: Re: What is keeping GDB in CVS ? From: Richard Earnshaw To: Daniel Jacobowitz Cc: gdb@sourceware.org, Samuel Bronson In-Reply-To: <20090619164943.GA16137@caradoc.them.org> References: <87r5xgqk0k.wl%naesten@gmail.com> <20090619162308.GA13968@caradoc.them.org> <20090619162801.GA14773@caradoc.them.org> <20090619163753.GA9700@ednor.casa.cgf.cx> <20090619164943.GA16137@caradoc.them.org> Content-Type: text/plain Date: Fri, 19 Jun 2009 16:56:00 -0000 Message-Id: <1245430587.11675.47.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: 2009-06/txt/msg00198.txt.bz2 On Fri, 2009-06-19 at 12:49 -0400, Daniel Jacobowitz wrote: > On Fri, Jun 19, 2009 at 12:37:53PM -0400, Christopher Faylor wrote: > > I still think that the various projects merged under the "src" umbrella > > should be pulled apart and given their own repositories. There is > > really, for instance, no reason for Cygwin or cgen, which are non-FSF > > projects, to be intermingled with gdb and binutils. > > > > However, I am very sympathetic to the notion that "It ain't broke..." > > The solution I'd like best, I think, is one with separate projects > that makes it easy to manually or automatically sync revisions from > the shared directories. This may be nothing more than some clever > push hooks, for instance to reject manual changes to bfd/ being pushed > to the central gdb repository and to automatically propogate changes > to bfd/ from binutils. Anyone feeling inspired enough to build a > proof-of-concept? > As someone who builds complete cross toolchains on a regular basis, I'd prefer for things not to become too fragmented. My preferred split would be for those tools that share source infrastructure to remain combined (binutils/gas/gdb) and maybe split out the others. It would be a right royal pain to have to edit three copies of an identical file when developing and testing -- it's bad enough having gcc outside of the infrastructure. R.