Re: Newlib/Cygwin now under GIT
On Tue, 10 Mar 2015, Corinna Vinschen wrote: > Hi fellow developers, > > > I'm happy to inform you that the move of Newlib/Cygwin from the src CVS > repository to the new, combined GIT repository is now final. I note that this repository includes the include/ directory, in its larger binutils-gdb form rather than the smaller GCC form. How much of this is actually relevant for newlib? Mostly it relates to libiberty and object file formats, for use of code that's not included in this repository (which does not include libiberty). If little or none of this code is actually used in newlib, it might make sense to remove the unused files so it's clear they do not need merging from the other repositories. (Apart from include/, various shared toplevel files and directories are out of sync between the three repositories - GCC, binutils-gdb, newlib-cygwin - and could do with someone identifying unmerged changes and applying them to the repositories missing them.) -- Joseph S. Myers jos...@codesourcery.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Newlib/Cygwin now under GIT
On Mar 10 17:03, Joseph Myers wrote: > On Tue, 10 Mar 2015, Corinna Vinschen wrote: > > > Hi fellow developers, > > > > > > I'm happy to inform you that the move of Newlib/Cygwin from the src CVS > > repository to the new, combined GIT repository is now final. > > I note that this repository includes the include/ directory, in its larger > binutils-gdb form rather than the smaller GCC form. > > How much of this is actually relevant for newlib? Keep in mind that this is a combined repo for newlib and Cygwin. Cygwin needs include/ for its dumper tool, which is a helper to create core files readable by GDB. It includes bfd.h elf/common.h elf/external.h and all files included by those. > Mostly it relates to > libiberty and object file formats, for use of code that's not included in > this repository (which does not include libiberty). If little or none of > this code is actually used in newlib, it might make sense to remove the > unused files so it's clear they do not need merging from the other > repositories. Of course, I have no problems to remove unused files, just not now. I'm still looking for a small problem in the repo, so please no unsolicited pushes for now. > (Apart from include/, various shared toplevel files and directories are > out of sync between the three repositories - GCC, binutils-gdb, > newlib-cygwin - and could do with someone identifying unmerged changes and > applying them to the repositories missing them.) This is a common problem. I guess newlib/cygwin got the oldest set and, afaik, the GCC toplevel stuff is kind of the master. It would be nice if we had some automatism in place to keep all former src repos in sync. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpGPEk0SYIjD.pgp Description: PGP signature
Re: Newlib/Cygwin now under GIT
[Somehow I managed to drop newlib from the recipient list. Re-added] On Mar 10 19:19, Corinna Vinschen wrote: > On Mar 10 17:03, Joseph Myers wrote: > > On Tue, 10 Mar 2015, Corinna Vinschen wrote: > > > > > Hi fellow developers, > > > > > > > > > I'm happy to inform you that the move of Newlib/Cygwin from the src CVS > > > repository to the new, combined GIT repository is now final. > > > > I note that this repository includes the include/ directory, in its larger > > binutils-gdb form rather than the smaller GCC form. > > > > How much of this is actually relevant for newlib? > > Keep in mind that this is a combined repo for newlib and Cygwin. Cygwin > needs include/ for its dumper tool, which is a helper to create core > files readable by GDB. It includes > > bfd.h > elf/common.h > elf/external.h > > and all files included by those. > > > Mostly it relates to > > libiberty and object file formats, for use of code that's not included in > > this repository (which does not include libiberty). If little or none of > > this code is actually used in newlib, it might make sense to remove the > > unused files so it's clear they do not need merging from the other > > repositories. > > Of course, I have no problems to remove unused files, just not > now. I'm still looking for a small problem in the repo, so please > no unsolicited pushes for now. The problems in the repo are fixed. If you had a problem accessing the repo in the last couple of minutes, it was me moving the problematic repo out and a repaired repo back into place. Sorry about that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgprtI9ZDvbzs.pgp Description: PGP signature
Re: Newlib/Cygwin now under GIT
> This is a common problem. I guess newlib/cygwin got the oldest set > and, afaik, the GCC toplevel stuff is kind of the master. It would > be nice if we had some automatism in place to keep all former src > repos in sync. There was never any agreement on who the "master" was for toplevel sources - no repo was willing to give up control to the other, so no automatic mirroring was ever done, unlike the libiberty/include mirror, where src agreed to let gcc be the master. Also, for the record, I do not wish to, nor do I intend to, provide any automated merging services for git repos. I don't like git and I'd rather not use it if I don't have to. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
