From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16144 invoked by alias); 31 Aug 2013 02:05:29 -0000 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 Received: (qmail 16121 invoked by uid 89); 31 Aug 2013 02:05:29 -0000 Received: from arjuna.pair.com (HELO arjuna.pair.com) (209.68.5.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with SMTP; Sat, 31 Aug 2013 02:05:29 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00,KHOP_THREADED autolearn=ham version=3.3.2 X-HELO: arjuna.pair.com Received: (qmail 26763 invoked by uid 3006); 31 Aug 2013 02:05:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 31 Aug 2013 02:05:25 -0000 Date: Sat, 31 Aug 2013 02:05:00 -0000 From: Hans-Peter Nilsson To: "Joseph S. Myers" cc: Tom Tromey , GDB Development , Binutils Development Subject: Re: A Proposal to Move to Git In-Reply-To: Message-ID: References: <8738q4gj7a.fsf@fleche.redhat.com> User-Agent: Alpine 2.02 (BSF 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2013-08/txt/msg00135.txt.bz2 On Fri, 30 Aug 2013, Joseph S. Myers wrote: > To build just one project, use --disable- options (this is > already generically supported at toplevel). It would be useful for there > to be documentation listing sets of such options to use for building > particular subsets of projects. Hah, if I've ever heard of that --disable-, I've certainly forgot about it! :) It's not something I expect to be maintained and stable until actually documented as a suggested work-flow. Anyway, I'd prefer to generate and autotest from src-release-generated tarballs, as that's what's released and what needs to work anyway, for projects actually released. A good thing: two tests for one. (Maybe there is already a separate autotester actually generating and testing release-snapshots.) > > At first I thought there was a huge inconvenience to projects > > left in the cold with CVS, but it it's less huge, it seems they > > will still be able to continue as they were - *except* they > > won't be able to update the shared files like configure.ac. > > Rather, changing shared files now needs three repositories rather than two > to change. If we can get agreement on GCC as the master, this could be > automated as it is for libiberty (check into GCC and let the automatic > process merge to the others). Or two repos rather than one and agreement whether src-CVS or the new git is the master; some files are not in GCC. > > To summarize the actions I want: > > - Git migrations and work-flow offered for remaining projects > > (like newlib and cgen). > > By design, it's for each project to choose to migrate or not, to its own > repository, independently, including choosing whether git is the version > control system they want at all. For other projects not to be severely inconvenienced (i.e. to actually leave them free to choose) we assume here that the src CVS repo remains updated regarding shared files. I did not take that for granted; it seemed that shared directories would remain read-only, but I guess that wasn't actually intended. > As I noted in , cgen > doesn't appear to use the shared toplevel at all, so if it moves out of > src, it would just be the cgen directory moving without a copy of anything > at toplevel; with regard to binutils+gdb, it's just another build tool. Still, the work-flow of using it will change (for sure for cgen-generated binutils and sim files) and the new work-flow of cgen development (both of and with) will have to be tested and documented. For sim, that's --enable-cgen-maint which now'll require an argument. It seems it'd almost work already except it'd have to live in a subdir called "lib" below the argument dir, which seems unnecessary. brgds, H-P