This is the mail archive of the
mailing list for the binutils project.
Re: A Proposal to Move to Git
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, GDB Development <gdb at sourceware dot org>, Binutils Development <binutils at sourceware dot org>
- Date: Fri, 30 Aug 2013 22:05:25 -0400 (EDT)
- Subject: Re: A Proposal to Move to Git
- Authentication-results: sourceware.org; auth=none
- References: <8738q4gj7a dot fsf at fleche dot redhat dot com> <alpine dot BSF dot 2 dot 02 dot 1308301744330 dot 46991 at arjuna dot pair dot com> <Pine dot LNX dot 4 dot 64 dot 1308302322360 dot 22363 at digraph dot polyomino dot org dot uk>
On Fri, 30 Aug 2013, Joseph S. Myers wrote:
> To build just one project, use --disable-<directory> 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-<subdir>, 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
> > 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 <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>, 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.