Re: [PATCH 1/2] Bump to autoconf 2.69 and automake 1.15.1

Simon Marchi
2018-06-16T03:05:37Z

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