merging from gcc

merging from gcc

[Tom Tromey]

I've finally set up some semi-automatic merging from gcc to
binutils-gdb.git.

Currently the process is not fully automated.  I have it set up to
notify me when patches are available.

I can make my script available if anybody cares.


I'm doing the first push now.  Please let me know if there are any
problems.

Tom

Re: merging from gcc

[Doug Evans]

On Fri, Nov 8, 2013 at 10:11 AM, Tom Tromey <tromey@redhat.com> wrote:
> I've finally set up some semi-automatic merging from gcc to
> binutils-gdb.git.
>
> Currently the process is not fully automated.  I have it set up to
> notify me when patches are available.
>
> I can make my script available if anybody cares.
>
>
> I'm doing the first push now.  Please let me know if there are any
> problems.

Hi.

Do you know if it's written down anywhere exactly what is copied?
I know $src/include isn't (or wasn't) just a blanket copy, and can
never remember
the details, and am curious if anything has changed in The New World.

Re: merging from gcc

[Tom Tromey]

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> Do you know if it's written down anywhere exactly what is copied?
Doug> I know $src/include isn't (or wasn't) just a blanket copy, and can
Doug> never remember
Doug> the details, and am curious if anything has changed in The New World.

@files = ("Makefile.tpl", "Makefile.def", "Makefile.in",
	  "configure.ac", "configure", "config", "install-sh",
	  "missing", "depcomp", "config.guess", "config.sub",
	  "compile", "ylwrap", "config.rpath", "ltgcc.m4",
	  "ltmain.sh", "ltoptions.m4", "ltsugar.m4", "ltversion.m4",
	  "lt~obsolete.m4");

$dir_rx = qr,^(libiberty|include|intl|libdecnumber)/,;


Files in "include" are then checked for existence in binutils-gdb.git.

Tom

Re: merging from gcc

[Doug Evans]

On Fri, Nov 8, 2013 at 10:41 AM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Doug" == Doug Evans <dje@google.com> writes:
>
> Doug> Do you know if it's written down anywhere exactly what is copied?
> Doug> I know $src/include isn't (or wasn't) just a blanket copy, and can
> Doug> never remember
> Doug> the details, and am curious if anything has changed in The New World.
>
> @files = ("Makefile.tpl", "Makefile.def", "Makefile.in",
>           "configure.ac", "configure", "config", "install-sh",
>           "missing", "depcomp", "config.guess", "config.sub",
>           "compile", "ylwrap", "config.rpath", "ltgcc.m4",
>           "ltmain.sh", "ltoptions.m4", "ltsugar.m4", "ltversion.m4",
>           "lt~obsolete.m4");
>
> $dir_rx = qr,^(libiberty|include|intl|libdecnumber)/,;
>
>
> Files in "include" are then checked for existence in binutils-gdb.git.

Thanks.

I added something here.
https://sourceware.org/gdb/wiki/GDBAdministrivia

I'm happy to enhance it or just replace it with a link if it's already
documented elsewhere.

Re: merging from gcc

[DJ Delorie]

> I'm happy to enhance it or just replace it with a link if it's already
> documented elsewhere.

what we have is in src/MAINTAINERS:

Makefile.*; configure; configure.ac; src-release
	Any global maintainer can approve changes to these
	files, but they should be aware	that they need to
	be kept in sync with their counterparts in the GCC
	repository.  Also please notify the following of
	any committed patches:
		binutils@sourceware.org
		gdb-patches@sourceware.org

config.guess; config.sub; readline/support/config.{sub,guess}
	config: http://savannah.gnu.org/projects/config
	Patches to config-patches@gnu.org.
	Changes need to be done in tandem with the official CONFIG
	sources or submitted to the master file maintainer and brought
	in via a merge.  When updating any of these files, please be
	sure to update all of them.
	Please notify the following of any committed patches:
		binutils@sourceware.org
		gdb-patches@sourceware.org

include/
	See binutils/, gdb/, sid/, gcc/, libiberty/ etc.

intl/; config.rhost; libiberty/; libiberty's part of include/;
compile; depcomp; install-sh; missing; ylwrap; config/
	gcc: http://gcc.gnu.org
	Changes need to be done in tandem with the official GCC
	sources or submitted to the master file maintainer and brought
	in via a merge.  Note: approved patches in gcc's libiberty or
	intl are automatically approved in this libiberty and intl also;
	feel free to merge them yourself if needed sooner than the next
	merge.  Otherwise, changes are automatically merged, usually
	within a day.

libdecnumber/
	See libiberty.  The master copy of this directory is in the GCC
	repository.


ltconfig; ltmain.sh; ltcf-*.sh
	libtool: http://www.gnu.org/software/libtool/
	Changes need to be done in tandem with the official LIBTOOL
	sources or submitted to the master file maintainer and brought
	in via a merge.

Re: merging from gcc

[Doug Evans]

On Fri, Nov 8, 2013 at 11:53 AM, DJ Delorie <dj@redhat.com> wrote:
>
>> I'm happy to enhance it or just replace it with a link if it's already
>> documented elsewhere.
>
> what we have is in src/MAINTAINERS:
>
> Makefile.*; configure; configure.ac; src-release
>         Any global maintainer can approve changes to these
>         files, but they should be aware that they need to
>         be kept in sync with their counterparts in the GCC
>         repository.  Also please notify the following of
>         any committed patches:
>                 binutils@sourceware.org
>                 gdb-patches@sourceware.org
>
> config.guess; config.sub; readline/support/config.{sub,guess}
>         config: http://savannah.gnu.org/projects/config
>         Patches to config-patches@gnu.org.
>         Changes need to be done in tandem with the official CONFIG
>         sources or submitted to the master file maintainer and brought
>         in via a merge.  When updating any of these files, please be
>         sure to update all of them.
>         Please notify the following of any committed patches:
>                 binutils@sourceware.org
>                 gdb-patches@sourceware.org
>
> include/
>         See binutils/, gdb/, sid/, gcc/, libiberty/ etc.
>
> intl/; config.rhost; libiberty/; libiberty's part of include/;
> compile; depcomp; install-sh; missing; ylwrap; config/
>         gcc: http://gcc.gnu.org
>         Changes need to be done in tandem with the official GCC
>         sources or submitted to the master file maintainer and brought
>         in via a merge.  Note: approved patches in gcc's libiberty or
>         intl are automatically approved in this libiberty and intl also;
>         feel free to merge them yourself if needed sooner than the next
>         merge.  Otherwise, changes are automatically merged, usually
>         within a day.
>
> libdecnumber/
>         See libiberty.  The master copy of this directory is in the GCC
>         repository.
>
>
> ltconfig; ltmain.sh; ltcf-*.sh
>         libtool: http://www.gnu.org/software/libtool/
>         Changes need to be done in tandem with the official LIBTOOL
>         sources or submitted to the master file maintainer and brought
>         in via a merge.

I'd be happy if this text were added.

I will check it in if there are no objections.
I'm happy to change it as desired as well.

2013-11-11  Doug Evans  <dje@google.com>

        * MAINTAINERS: Clarify ownership of include.

diff --git a/MAINTAINERS b/MAINTAINERS
index dd8601b..b09fbc0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -47,7 +47,10 @@ gdb/; readline/; sim/; GDB's part of include/
        See also gdb/MAINTAINERS and sim/MAINTAINERS.

 include/
-       See binutils/, gdb/, sid/, gcc/, libiberty/ etc.
+       The rule is that if the file exists in the gcc tree
+       then gcc owns it.  Thus you have to look at the gcc tree
+       to know whether any particular file is owned by gcc.
+       See also binutils/, gdb/, sid/, gcc/, libiberty/ etc.

 intl/; config.rhost; libiberty/; libiberty's part of include/
 compile; depcomp; install-sh; missing; ylwrap; config/

Re: merging from gcc

[Doug Evans]

On Mon, Nov 11, 2013 at 11:45 AM, Doug Evans <dje@google.com> wrote:
> On Fri, Nov 8, 2013 at 11:53 AM, DJ Delorie <dj@redhat.com> wrote:
>>
>>> I'm happy to enhance it or just replace it with a link if it's already
>>> documented elsewhere.
>>
>> what we have is in src/MAINTAINERS:
>>
>> Makefile.*; configure; configure.ac; src-release
>>         Any global maintainer can approve changes to these
>>         files, but they should be aware that they need to
>>         be kept in sync with their counterparts in the GCC
>>         repository.  Also please notify the following of
>>         any committed patches:
>>                 binutils@sourceware.org
>>                 gdb-patches@sourceware.org
>>
>> config.guess; config.sub; readline/support/config.{sub,guess}
>>         config: http://savannah.gnu.org/projects/config
>>         Patches to config-patches@gnu.org.
>>         Changes need to be done in tandem with the official CONFIG
>>         sources or submitted to the master file maintainer and brought
>>         in via a merge.  When updating any of these files, please be
>>         sure to update all of them.
>>         Please notify the following of any committed patches:
>>                 binutils@sourceware.org
>>                 gdb-patches@sourceware.org
>>
>> include/
>>         See binutils/, gdb/, sid/, gcc/, libiberty/ etc.
>>
>> intl/; config.rhost; libiberty/; libiberty's part of include/;
>> compile; depcomp; install-sh; missing; ylwrap; config/
>>         gcc: http://gcc.gnu.org
>>         Changes need to be done in tandem with the official GCC
>>         sources or submitted to the master file maintainer and brought
>>         in via a merge.  Note: approved patches in gcc's libiberty or
>>         intl are automatically approved in this libiberty and intl also;
>>         feel free to merge them yourself if needed sooner than the next
>>         merge.  Otherwise, changes are automatically merged, usually
>>         within a day.
>>
>> libdecnumber/
>>         See libiberty.  The master copy of this directory is in the GCC
>>         repository.
>>
>>
>> ltconfig; ltmain.sh; ltcf-*.sh
>>         libtool: http://www.gnu.org/software/libtool/
>>         Changes need to be done in tandem with the official LIBTOOL
>>         sources or submitted to the master file maintainer and brought
>>         in via a merge.
>
> I'd be happy if this text were added.
>
> I will check it in if there are no objections.
> I'm happy to change it as desired as well.
>
> 2013-11-11  Doug Evans  <dje@google.com>
>
>         * MAINTAINERS: Clarify ownership of include.
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index dd8601b..b09fbc0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -47,7 +47,10 @@ gdb/; readline/; sim/; GDB's part of include/
>         See also gdb/MAINTAINERS and sim/MAINTAINERS.
>
>  include/
> -       See binutils/, gdb/, sid/, gcc/, libiberty/ etc.
> +       The rule is that if the file exists in the gcc tree
> +       then gcc owns it.  Thus you have to look at the gcc tree
> +       to know whether any particular file is owned by gcc.
> +       See also binutils/, gdb/, sid/, gcc/, libiberty/ etc.
>
>  intl/; config.rhost; libiberty/; libiberty's part of include/
>  compile; depcomp; install-sh; missing; ylwrap; config/

Hi.
Going through my mail I see I didn't follow through on this.

Just a heads up before I check this in.
[This is to gdb+binutils MAINTAINERS file.]

The MAINTAINERS file says no changelog entries for it,
though I do see some in the toplevel ChangeLog.
My plan is to follow what MAINTAINERS says and not
update ChangeLog.
[If people want a ChangeLog entry then let's first
agree to update the text in MAINTAINERS.]

Re: merging from gcc

[DJ Delorie]

Doug Evans <dje@google.com> writes:
> I know $src/include isn't (or wasn't) just a blanket copy, and can
> never remember the details, and am curious if anything has changed in
> The New World.

The rule for include/ has always been: if a file exists in both repos,
gcc owns it.

Re: merging from gcc

[Doug Evans]

On Fri, Nov 8, 2013 at 11:04 AM, DJ Delorie <dj@redhat.com> wrote:
>
> Doug Evans <dje@google.com> writes:
>> I know $src/include isn't (or wasn't) just a blanket copy, and can
>> never remember the details, and am curious if anything has changed in
>> The New World.
>
> The rule for include/ has always been: if a file exists in both repos,
> gcc owns it.

I think it's the fact that the granularity is per-file and I can't
know from just looking at the binutils-gdb tree, that keeps me
cautious.

Re: merging from gcc

[Pedro Alves]

On 11/08/2013 06:11 PM, Tom Tromey wrote:
> I can make my script available if anybody cares.

I'd suggest checking it in to src/gdb/contrib,
src/contrib or something/somewhere like that, to increase
bus factor.

Thanks,
-- 
Pedro Alves

Re: merging from gcc

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

>> I can make my script available if anybody cares.

Pedro> I'd suggest checking it in to src/gdb/contrib,
Pedro> src/contrib or something/somewhere like that, to increase
Pedro> bus factor.

I put it here:

    https://github.com/tromey/gdb-admin

Tom

Re: merging from gcc

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

On Fri, 2013-11-08 11:11:09 -0700, Tom Tromey <tromey@redhat.com> wrote:
> I've finally set up some semi-automatic merging from gcc to
> binutils-gdb.git.

I've got some script running on my own (to be started manually), maybe
I'd have a look if I compare something else?

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:                   ...und wenn Du denkst, es geht nicht mehr,
the second  :                          kommt irgendwo ein Lichtlein her.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: merging from gcc

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

On Fri, 2013-11-08 11:11:09 -0700, Tom Tromey <tromey@redhat.com> wrote:
> I've finally set up some semi-automatic merging from gcc to
> binutils-gdb.git.

What about merging other external stuff? For the binutils/gdb repo, I
have this in mind:

From config.git:
config-ro-git/config.guess
config-ro-git/config.sub

From automake.git:
automake-ro-git/lib/compile
automake-ro-git/lib/depcomp
automake-ro-git/lib/install-sh
automake-ro-git/lib/missing
automake-ro-git/lib/mkinstalldirs
automake-ro-git/lib/ylwrap

From gnulib.git:
gnulib-ro-git/build-aux/move-if-change

If it's okay to commit these, I'll prepare a patch and push it.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:         Alles wird gut! ...und heute wirds schon ein bißchen besser.
the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: merging from gcc

[Tom Tromey]

>>>>> "Jan-Benedict" == Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:

Jan-Benedict> What about merging other external stuff? For the
Jan-Benedict> binutils/gdb repo, I have this in mind:
[...]
Jan-Benedict> If it's okay to commit these, I'll prepare a patch and push it.

I think they have to go through gcc first.

Tom

Re: merging from gcc

[Joseph S. Myers]

On Sun, 10 Nov 2013, Jan-Benedict Glaw wrote:

> On Fri, 2013-11-08 11:11:09 -0700, Tom Tromey <tromey@redhat.com> wrote:
> > I've finally set up some semi-automatic merging from gcc to
> > binutils-gdb.git.
> 
> What about merging other external stuff? For the binutils/gdb repo, I
> have this in mind:

Any such merges of shared files maintained elsewhere, please update all of 
GCC SVN, binutils-gdb git and src CVS at the same time, rather than just a 
subset.  (As the files you mention should always come verbatim from 
upstream, you don't need to worry about cases where people have changed 
the different repositories in different ways and you have to do a 
multi-way merge - you should just be able to copy in the latest version to 
all three repositories.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: merging from gcc

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

On Mon, 2013-11-11 16:54:20 +0000, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Sun, 10 Nov 2013, Jan-Benedict Glaw wrote:
> > On Fri, 2013-11-08 11:11:09 -0700, Tom Tromey <tromey@redhat.com> wrote:
> > > I've finally set up some semi-automatic merging from gcc to
> > > binutils-gdb.git.
> > 
> > What about merging other external stuff? For the binutils/gdb repo, I
> > have this in mind:
> 
> Any such merges of shared files maintained elsewhere, please update all of 
> GCC SVN, binutils-gdb git and src CVS at the same time, rather than just a 
> subset.  (As the files you mention should always come verbatim from 
> upstream, you don't need to worry about cases where people have changed 
> the different repositories in different ways and you have to do a 
> multi-way merge - you should just be able to copy in the latest version to 
> all three repositories.)

I thought src CVS is dead (aka read-only)?  My script also watched the
other mentioned files, but I've never acted upon them until now. Would
be nice to have a general policy, which seems to just import them to
all repos (`gcc' and 'binutils-gdb') at the same time. For `src', I
think that commits won't work any longer, though I haven't checked.
Indeed, since some days, I only get GIT-style commit messages for
binutils-git, but nothing that supports the fact of a writeable `src'
repo any longer...

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:         "really soon now":      an unspecified period of time, likly to
the second  :                                 be greater than any reasonable definition
                                              of "soon".

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: merging from gcc

[Joseph S. Myers]

On Mon, 11 Nov 2013, Jan-Benedict Glaw wrote:

> I thought src CVS is dead (aka read-only)?  My script also watched the

src CVS is active for newlib and Cygwin (winsup/).  (There are several 
other projects in there, but they don't have significant activity.  If 
newlib and Cygwin were to move out - which is a matter for those 
communities - I'd be happy saying shared files should be kept in sync 
between GCC, binutils-gdb, newlib and Cygwin repositories and that src CVS 
should be made readonly.)

-- 
Joseph S. Myers
joseph@codesourcery.com