From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29463 invoked by alias); 19 Jun 2009 19:22:55 -0000 Received: (qmail 29454 invoked by uid 22791); 19 Jun 2009 19:22:55 -0000 X-Spam-Check-By: sourceware.org Received: from pool-98-110-183-121.bstnma.fios.verizon.net (HELO cgf.cx) (98.110.183.121) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Jun 2009 19:22:47 +0000 Received: from ednor.cgf.cx (ednor.casa.cgf.cx [192.168.187.5]) by cgf.cx (Postfix) with ESMTP id CE59413C065 for ; Fri, 19 Jun 2009 15:22:36 -0400 (EDT) Received: by ednor.cgf.cx (Postfix, from userid 201) id C078F2B383; Fri, 19 Jun 2009 15:22:36 -0400 (EDT) Date: Fri, 19 Jun 2009 19:22:00 -0000 From: Christopher Faylor To: gdb@sourceware.org Subject: Re: What is keeping GDB in CVS ? Message-ID: <20090619192236.GA10670@ednor.casa.cgf.cx> Mail-Followup-To: gdb@sourceware.org References: <87r5xgqk0k.wl%naesten@gmail.com> <20090619162308.GA13968@caradoc.them.org> <20090619162801.GA14773@caradoc.them.org> <20090619163753.GA9700@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) 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/msg00203.txt.bz2 On Fri, Jun 19, 2009 at 05:17:54PM +0000, Joseph S. Myers wrote: >On Fri, 19 Jun 2009, 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. > >The cpu directory, however, does need including in binutils checkouts >because it provides the source code to generated files there, even if >it might otherwise be seen as part of cgen. (I agree regarding Cygwin; >likewise the copies of tcl and tk that are still present in src >checkouts.) > >However, we have so far been unable to keep shared files reliably in >sync between gcc and src. The following files should be identical, but >aren't right now. > >Makefile.def Makefile.in Makefile.tpl configure configure.ac >config/ChangeLog config/lead-dot.m4 config/mh-cygwin config/tls.m4 >config/unwind_ipinfo.m4 config/warnings.m4 include/ChangeLog-9103 So maybe they shouldn't be *shared*. There could be just one copy. I think everyone knows that you'll have problems as soon as you start duplicating data. This is no exception. I doubt that the gcc project would think it was a good idea but we could just break libiberty and the top-level configury into a separate repository too. Then when you make a change to a file, everyone gets the change and people will squawk immediately when you make a change to one of these files for gcc which happens to break a binutils build. cgf