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
next prev parent 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