Re: A Proposal to Move to Git

[Hans-Peter Nilsson <hp at bitrange dot com>]

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
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 <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.

brgds, H-P