update automake version to 1.11.6

  Debian stable (wheezy) and newer only have 1.11.6.
Ubuntu Trusty and newer only have 1.11.6.
Gentoo dropped <=1.11.5 2 years ago.
Fedora R17 was the last one to offer 1.11.x (it was 1.11.6).
Centos 7 doesn't offer any 1.11.x version.
OpenSUSE 12.2 was the last one to offer 1.11.x.
Arch Linux dropped 1.11.x 3 years ago.
Mageia 2 was the last one to offer 1.11.x.

So anyone who readily has access to automake 1.11.[0-5] is using a two
year old distro that is no longer supported.  Lets use 1.11.6 as it's
the only 1.11.x version that is easily available.

2015-03-14  Mike Frysinger  <vapier@gentoo.org>

	* README-maintainer-mode: Update automake to 1.11.6.
---
 README-maintainer-mode | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
  

> Debian stable (wheezy) and newer only have 1.11.6.
> Ubuntu Trusty and newer only have 1.11.6.
> Gentoo dropped <=1.11.5 2 years ago.
> Fedora R17 was the last one to offer 1.11.x (it was 1.11.6).
> Centos 7 doesn't offer any 1.11.x version.
> OpenSUSE 12.2 was the last one to offer 1.11.x.
> Arch Linux dropped 1.11.x 3 years ago.
> Mageia 2 was the last one to offer 1.11.x.
> 
> So anyone who readily has access to automake 1.11.[0-5] is using a two
> year old distro that is no longer supported.  Lets use 1.11.6 as it's
> the only 1.11.x version that is easily available.
> 
> 2015-03-14  Mike Frysinger  <vapier@gentoo.org>
> 
> 	* README-maintainer-mode: Update automake to 1.11.6.

FWIW, I tend to avoid using the auto-tools already installed, because
I don't know what patches they might contain. Those patches can result
in small differences which inexplicably show up when you regenerate
some files after making some modifications. That's why I rebuilt
them all from source, and use them when regenerating files.

All in all, I'm not against switching to 1.11.6 but we should then
regenerate all affected files now, and I would prefer it if that was
done using an unmodified release rather than one that might have been
modified by the distro.
  

On Thu, Mar 19, 2015 at 5:06 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Debian stable (wheezy) and newer only have 1.11.6.
>> Ubuntu Trusty and newer only have 1.11.6.
>> Gentoo dropped <=1.11.5 2 years ago.
>> Fedora R17 was the last one to offer 1.11.x (it was 1.11.6).
>> Centos 7 doesn't offer any 1.11.x version.
>> OpenSUSE 12.2 was the last one to offer 1.11.x.
>> Arch Linux dropped 1.11.x 3 years ago.
>> Mageia 2 was the last one to offer 1.11.x.
>>
>> So anyone who readily has access to automake 1.11.[0-5] is using a two
>> year old distro that is no longer supported.  Lets use 1.11.6 as it's
>> the only 1.11.x version that is easily available.
>>
>> 2015-03-14  Mike Frysinger  <vapier@gentoo.org>
>>
>>       * README-maintainer-mode: Update automake to 1.11.6.
>
> FWIW, I tend to avoid using the auto-tools already installed, because
> I don't know what patches they might contain. Those patches can result
> in small differences which inexplicably show up when you regenerate
> some files after making some modifications. That's why I rebuilt
> them all from source, and use them when regenerating files.
>
> All in all, I'm not against switching to 1.11.6 but we should then
> regenerate all affected files now, and I would prefer it if that was
> done using an unmodified release rather than one that might have been
> modified by the distro.

+1 on avoiding distro releases.
  

On 19 Mar 2015 15:59, Doug Evans wrote:
> On Thu, Mar 19, 2015 at 5:06 AM, Joel Brobecker wrote:
> >> Debian stable (wheezy) and newer only have 1.11.6.
> >> Ubuntu Trusty and newer only have 1.11.6.
> >> Gentoo dropped <=1.11.5 2 years ago.
> >> Fedora R17 was the last one to offer 1.11.x (it was 1.11.6).
> >> Centos 7 doesn't offer any 1.11.x version.
> >> OpenSUSE 12.2 was the last one to offer 1.11.x.
> >> Arch Linux dropped 1.11.x 3 years ago.
> >> Mageia 2 was the last one to offer 1.11.x.
> >>
> >> So anyone who readily has access to automake 1.11.[0-5] is using a two
> >> year old distro that is no longer supported.  Lets use 1.11.6 as it's
> >> the only 1.11.x version that is easily available.
> >>
> >> 2015-03-14  Mike Frysinger  <vapier@gentoo.org>
> >>
> >>       * README-maintainer-mode: Update automake to 1.11.6.
> >
> > FWIW, I tend to avoid using the auto-tools already installed, because
> > I don't know what patches they might contain. Those patches can result
> > in small differences which inexplicably show up when you regenerate
> > some files after making some modifications. That's why I rebuilt
> > them all from source, and use them when regenerating files.
> >
> > All in all, I'm not against switching to 1.11.6 but we should then
> > regenerate all affected files now, and I would prefer it if that was
> > done using an unmodified release rather than one that might have been
> > modified by the distro.
> 
> +1 on avoiding distro releases.

if we follow this logic, why aren't autotools part of the repo, either directly 
(like readline) or indirectly (git submodules) ?  requiring every developer to 
independently correctly download&build&install a custom version of autotools in 
their system is, frankly, unreasonable.

in Gentoo i've made it dirt simple for people -- older versions of autoconf are 
available to emerge in parallel and you can select via `autoconf-2.64` or by 
exporting WANT_AUTOCONF=2.64.  but i don't think making Gentoo a requirement 
would be approved :D.
-mike
  

On Thu, Mar 19, 2015 at 4:04 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 19 Mar 2015 15:59, Doug Evans wrote:
>> On Thu, Mar 19, 2015 at 5:06 AM, Joel Brobecker wrote:
>> >> Debian stable (wheezy) and newer only have 1.11.6.
>> >> Ubuntu Trusty and newer only have 1.11.6.
>> >> Gentoo dropped <=1.11.5 2 years ago.
>> >> Fedora R17 was the last one to offer 1.11.x (it was 1.11.6).
>> >> Centos 7 doesn't offer any 1.11.x version.
>> >> OpenSUSE 12.2 was the last one to offer 1.11.x.
>> >> Arch Linux dropped 1.11.x 3 years ago.
>> >> Mageia 2 was the last one to offer 1.11.x.
>> >>
>> >> So anyone who readily has access to automake 1.11.[0-5] is using a two
>> >> year old distro that is no longer supported.  Lets use 1.11.6 as it's
>> >> the only 1.11.x version that is easily available.
>> >>
>> >> 2015-03-14  Mike Frysinger  <vapier@gentoo.org>
>> >>
>> >>       * README-maintainer-mode: Update automake to 1.11.6.
>> >
>> > FWIW, I tend to avoid using the auto-tools already installed, because
>> > I don't know what patches they might contain. Those patches can result
>> > in small differences which inexplicably show up when you regenerate
>> > some files after making some modifications. That's why I rebuilt
>> > them all from source, and use them when regenerating files.
>> >
>> > All in all, I'm not against switching to 1.11.6 but we should then
>> > regenerate all affected files now, and I would prefer it if that was
>> > done using an unmodified release rather than one that might have been
>> > modified by the distro.
>>
>> +1 on avoiding distro releases.
>
> if we follow this logic, why aren't autotools part of the repo, either directly
> (like readline) or indirectly (git submodules) ?  requiring every developer to
> independently correctly download&build&install a custom version of autotools in
> their system is, frankly, unreasonable.
>
> in Gentoo i've made it dirt simple for people -- older versions of autoconf are
> available to emerge in parallel and you can select via `autoconf-2.64` or by
> exporting WANT_AUTOCONF=2.64.  but i don't think making Gentoo a requirement
> would be approved :D.
> -mike

IIRC, There used to be copies of at least one of autoconf/automake on
sourceware because there were local patches we needed.  They were
eventually deleted because there was no longer a need for them, and
when we upgrade to a new version it's easier to just get the release
from ftp.gnu.org (or wherever).

It's happened before that distro releases of autoconf/automake
contained local mods that generated noisy diffs. A distro
autoconf-2.64 is not necessarily a real autoconf-2.64 (no local mods).
Requiring everyone to use the same version in order to avoid noisy
changes is desirable, and requiring people to download/install pure
FSF copies doesn't really seem that onerous.
  

On 20 Mar 2015 16:58, Doug Evans wrote:
> On Thu, Mar 19, 2015 at 4:04 PM, Mike Frysinger wrote:
> > On 19 Mar 2015 15:59, Doug Evans wrote:
> >> On Thu, Mar 19, 2015 at 5:06 AM, Joel Brobecker wrote:
> >> >> Debian stable (wheezy) and newer only have 1.11.6.
> >> >> Ubuntu Trusty and newer only have 1.11.6.
> >> >> Gentoo dropped <=1.11.5 2 years ago.
> >> >> Fedora R17 was the last one to offer 1.11.x (it was 1.11.6).
> >> >> Centos 7 doesn't offer any 1.11.x version.
> >> >> OpenSUSE 12.2 was the last one to offer 1.11.x.
> >> >> Arch Linux dropped 1.11.x 3 years ago.
> >> >> Mageia 2 was the last one to offer 1.11.x.
> >> >>
> >> >> So anyone who readily has access to automake 1.11.[0-5] is using a two
> >> >> year old distro that is no longer supported.  Lets use 1.11.6 as it's
> >> >> the only 1.11.x version that is easily available.
> >> >>
> >> >> 2015-03-14  Mike Frysinger  <vapier@gentoo.org>
> >> >>
> >> >>       * README-maintainer-mode: Update automake to 1.11.6.
> >> >
> >> > FWIW, I tend to avoid using the auto-tools already installed, because
> >> > I don't know what patches they might contain. Those patches can result
> >> > in small differences which inexplicably show up when you regenerate
> >> > some files after making some modifications. That's why I rebuilt
> >> > them all from source, and use them when regenerating files.
> >> >
> >> > All in all, I'm not against switching to 1.11.6 but we should then
> >> > regenerate all affected files now, and I would prefer it if that was
> >> > done using an unmodified release rather than one that might have been
> >> > modified by the distro.
> >>
> >> +1 on avoiding distro releases.
> >
> > if we follow this logic, why aren't autotools part of the repo, either directly
> > (like readline) or indirectly (git submodules) ?  requiring every developer to
> > independently correctly download&build&install a custom version of autotools in
> > their system is, frankly, unreasonable.
> >
> > in Gentoo i've made it dirt simple for people -- older versions of autoconf are
> > available to emerge in parallel and you can select via `autoconf-2.64` or by
> > exporting WANT_AUTOCONF=2.64.  but i don't think making Gentoo a requirement
> > would be approved :D.
> 
> IIRC, There used to be copies of at least one of autoconf/automake on
> sourceware because there were local patches we needed.  They were
> eventually deleted because there was no longer a need for them, and
> when we upgrade to a new version it's easier to just get the release
> from ftp.gnu.org (or wherever).
> 
> It's happened before that distro releases of autoconf/automake
> contained local mods that generated noisy diffs. A distro
> autoconf-2.64 is not necessarily a real autoconf-2.64 (no local mods).

i'm aware of what distros can do -- i'm the maintainer of these packages in 
Gentoo, and i have included upstream fixes before.  and i've seen older versions 
include patches that were ... questionable.

> Requiring everyone to use the same version in order to avoid noisy
> changes is desirable, and requiring people to download/install pure
> FSF copies doesn't really seem that onerous.

i don't have a problem with requiring people to use the same exact version.
i do think that requiring them to build/install by hand is unreasonable.
it's pretty rare (by design) for projects to do this sort of thing (commit
the generated autotools), so it's pretty rare for this to be an issue, so
it's pretty rare for people to be required to manage this.  it's a throw
back to pre-distro days when people were used to building/install software
themselves, and it's unnecessary friction for new people to get into the 
development process today.  death by a thousand cuts and all that.

while i would like to see the autotools not be checked in in the first place, 
i'm not advocating for that here.  if we're going to make this a barrier for
entry, then why don't we make it a non-issue ?
-mike
  

On Sat, Mar 21, 2015 at 12:59 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> it's a throw
> back to pre-distro days when people were used to building/install software
> themselves, and it's unnecessary friction for new people to get into the
> development process today.  death by a thousand cuts and all that.

If you want to submit a patch to remove such generated files and try
to get it approved, go for it.
  

> > i don't have a problem with requiring people to use the same exact
> version.
> > i do think that requiring them to build/install by hand is
> > unreasonable.  it's pretty rare (by design) for projects to do this
> > sort of thing (commit the generated autotools), so it's pretty rare
> > for this to be an issue, so it's pretty rare for people to be
> > required to manage this.  it's a throw back to pre-distro days when
> > people were used to building/install software themselves, and it's
> > unnecessary friction for new people to get into the development
> > process today.  death by a thousand cuts and all that.
> 
> It's only a barrier for people who need to change the configure.ac or
> Makefile.am files, which is not most developers.

Agreed.

Also, I don't think that building autoconf and automake once every
few years, and then using that to generate the files is really that
much of a barrier. In the meantime, it allows us to avoid the noise
you get when slightly different versions generate slightly different
code. I personally do verify the changes in the configure files,
for instance, and ask myself whether each hunk I see makes sense
to me or not. Seeing unrelated changes because others used a different
version makes that process a little harder (and, most of the time,
I'll just start over, and push a patch that first regenerates the
file).
  

On Mon, Mar 23, 2015 at 5:46 AM, Joel Brobecker <brobecker@adacore.com> wrote:
>> > i don't have a problem with requiring people to use the same exact
>> version.
>> > i do think that requiring them to build/install by hand is
>> > unreasonable.  it's pretty rare (by design) for projects to do this
>> > sort of thing (commit the generated autotools), so it's pretty rare
>> > for this to be an issue, so it's pretty rare for people to be
>> > required to manage this.  it's a throw back to pre-distro days when
>> > people were used to building/install software themselves, and it's
>> > unnecessary friction for new people to get into the development
>> > process today.  death by a thousand cuts and all that.
>>
>> It's only a barrier for people who need to change the configure.ac or
>> Makefile.am files, which is not most developers.
>
> Agreed.
>
> Also, I don't think that building autoconf and automake once every
> few years, and then using that to generate the files is really that
> much of a barrier. In the meantime, it allows us to avoid the noise
> you get when slightly different versions generate slightly different
> code. I personally do verify the changes in the configure files,
> for instance, and ask myself whether each hunk I see makes sense
> to me or not. Seeing unrelated changes because others used a different
> version makes that process a little harder (and, most of the time,
> I'll just start over, and push a patch that first regenerates the
> file).

We should coordinate this with GCC.   I have been using autoconf
and automake specified in

https://gcc.gnu.org/install/prerequisites.html
  

> We should coordinate this with GCC.   I have been using autoconf
> and automake specified in
> 
> https://gcc.gnu.org/install/prerequisites.html

Looks like we are using the same versions.
  

On Mon, Mar 23, 2015 at 05:57:20AM -0700, H.J. Lu wrote:
> We should coordinate this with GCC.

I agree.  Using the same version of autotools for binutils+gdb+gcc is
a good idea.

Why are we talking about such a small upgrade though?  Wouldn't it
make more sense to move to the latest released autotools?  Not for new
features, but for the bug fixes that have accumulated over the years.
I know there have been bug reports about the versions we use..
eg. https://sourceware.org/bugzilla/show_bug.cgi?id=16948
  

On 23 Mar 2015 05:46, Joel Brobecker wrote:
> > > i don't have a problem with requiring people to use the same exact
> > version.
> > > i do think that requiring them to build/install by hand is
> > > unreasonable.  it's pretty rare (by design) for projects to do this
> > > sort of thing (commit the generated autotools), so it's pretty rare
> > > for this to be an issue, so it's pretty rare for people to be
> > > required to manage this.  it's a throw back to pre-distro days when
> > > people were used to building/install software themselves, and it's
> > > unnecessary friction for new people to get into the development
> > > process today.  death by a thousand cuts and all that.
> > 
> > It's only a barrier for people who need to change the configure.ac or
> > Makefile.am files, which is not most developers.
> 
> Agreed.

i hit it on every machine i want to develop on, and i don't have the luxury of 
running Gentoo on every system

> Also, I don't think that building autoconf and automake once every
> few years, and then using that to generate the files is really that
> much of a barrier.

multiplied by every machine you develop on, and every user that wants to make 
their own contribution here
-mike
  

On 24 Mar 2015 10:16, Alan Modra wrote:
> On Mon, Mar 23, 2015 at 05:57:20AM -0700, H.J. Lu wrote:
> > We should coordinate this with GCC.
> 
> I agree.  Using the same version of autotools for binutils+gdb+gcc is
> a good idea.
> 
> Why are we talking about such a small upgrade though?  Wouldn't it
> make more sense to move to the latest released autotools?  Not for new
> features, but for the bug fixes that have accumulated over the years.
> I know there have been bug reports about the versions we use..
> eg. https://sourceware.org/bugzilla/show_bug.cgi?id=16948

i don't have the cycles to shave that yak.  in this case, the minor update
(1) is fairly safe and (2) includes a good number of distros.
-mike
  

On Tue, 24 Mar 2015, Alan Modra wrote:

> Why are we talking about such a small upgrade though?  Wouldn't it
> make more sense to move to the latest released autotools?  Not for new
> features, but for the bug fixes that have accumulated over the years.

Remember if doing a major update including libtool about the 
incompatibility of libtool's notion of sysroots with GCC's, requiring 
apparently that libtool commit 3334f7ed5851ef1e96b052f2984c4acdbf39e20c is 
reverted from the version of libtool code used.