Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Joseph Myers <joseph@codesourcery.com>
Cc: gdb-patches@sourceware.org, binutils@sourceware.org,
	       Simon Marchi <simon.marchi@ericsson.com>
Subject: Re: [PATCH 1/2] Bump to autoconf 2.69 and automake 1.15.1
Date: Sat, 16 Jun 2018 03:05:00 -0000	[thread overview]
Message-ID: <b121f2e5-77e7-b63d-a540-3db5d8203082@polymtl.ca> (raw)
In-Reply-To: <alpine.DEB.2.20.1806151717390.20961@digraph.polyomino.org.uk>

On 2018-06-15 01:29 PM, Joseph Myers wrote:
> Questions:
> 
> * Are all the shared files and directories fully in sync between the GCC 
> and binutils-gdb trees before this patch?  Shared directories include 
> config, intl, parts of include, libdecnumber, libiberty, zlib, for 
> example.

- config: binutils-gdb is behind, needs syncing
- include: I'll need more precise guidance on how to sync
- intl: in sync
- libdecnumber: binutils-gdb is behind, needs syncing.  Except one patchlet that
  binutils-gdb has and gcc doesn't have which adds a TAGS target to the Makefile.
  Could one of you see if you could import that change to gcc?
- libiberty: binutils-gdb is behind, needs syncing
- zlib: binutils-gdb is behind, needs syncing

I'm sending a series that syncs config, libdecnumber, libiberty and zlib in a
moment.

> * Where you are changing shared files and directories, do any changes to 
> *non-generated* files other than config/override.m4 depend on the autoconf 
> / automake updates, or would such changes work equally well in the GCC 
> tree even in the absence of a version update there?

If we exclude the AC_PREREQ bumps from 2.64 to 2.69, only zlib has some
significant changes.  If I exclude the AC_PREREQ change, I am able to
regenerate the files using automake 1.11.6 and autoconf 2.64.  So it looks ok.

> If proposing to change only one tree at a time I think it's important to 
> take care to minimise the extra costs introduced for people synchronizing 
> changes between the two trees while the versions are out of sync.  To me, 
> that indicates that the shared files and directories should be fully in 
> sync before any changes making them deliberately out of sync are applied, 
> and that changes to non-generated files other than config/override.m4 
> should go in both places if they work in both places, so that the 
> differences immediately after the change is applied are only the required 
> ones (i.e. config/override.m4 and the generated files), so that anyone 
> then merging a subsequent change in future knows they expect to get back 
> to exactly that set of differences and no more.
> 
> (Shared files in the newlib-cygwin tree have been out of sync for a lot 
> longer.  So, while I think that tree also ought to have shared files in 
> sync, with changes being applied to all three trees (I don't know if 
> newlib-cygwin has any changes not present in the other trees), I don't 
> think it's immediately relevant to changes in the binutils-gdb tree right 
> now.)

Understood.  Hopefully the series I send will do the job.  I don't know if
GCC ever plans to switch to git, but using submodules would make it much
easier to share that code rather than do manual syncing.

Simon


  reply	other threads:[~2018-06-16  3:05 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-15  0:43 Simon Marchi
2018-06-15  0:46 ` [PATCH 2/2] Generated files Simon Marchi
2018-06-15  3:00   ` Simon Marchi
2018-06-15 14:22 ` [PATCH 1/2] Bump to autoconf 2.69 and automake 1.15.1 Nick Clifton
2018-06-15 14:38   ` Simon Marchi
2018-06-15 14:58     ` Nick Clifton
2018-06-15 15:14       ` Simon Marchi
2018-06-15 15:30         ` Nick Clifton
2018-06-15 15:38           ` Simon Marchi
2018-06-15 15:54             ` Nick Clifton
2018-06-16  1:39   ` Alan Modra
2018-06-16  3:56     ` Simon Marchi
2018-06-16  7:17       ` Andreas Schwab
2018-06-18  2:46       ` Alan Modra
2018-06-18  3:05         ` Simon Marchi
2018-06-18  9:42           ` Nick Clifton
2018-06-15 17:29 ` Joseph Myers
2018-06-16  3:05   ` Simon Marchi [this message]
2018-06-18 15:12     ` Joseph Myers
2018-06-18 15:32       ` Simon Marchi
2018-06-16 22:41 ` Andreas K. Huettel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b121f2e5-77e7-b63d-a540-3db5d8203082@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    --cc=joseph@codesourcery.com \
    --cc=simon.marchi@ericsson.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox