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

[Simon Marchi]

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