Re: Update GCC to autoconf 2.69, automake 1.15.1

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Update GCC to autoconf 2.69, automake 1.15.1

Thomas Koenig-6
Am 31.10.18 um 04:26 schrieb Joseph Myers:
> This patch (diffs to generated files omitted below) updates GCC to use
> autoconf 2.69 and automake 1.15.1.

I think this should fix PR 82856.  Maybe you could confirm that this
restores automake functionality with perl 5.6.26, and mention the PR
in the ChangeLog.

>
> Makefile.am:48: warning: source file 'caf/single.c' is in a subdirectory,
> Makefile.am:48: but option 'subdir-objects' is disabled
> automake: warning: possible forward-incompatibility.
> automake: At least a source file is in a subdirectory, but the 'subdir-objects'
> automake: automake option hasn't been enabled.  For now, the corresponding output
> automake: object file(s) will be placed in the top-level directory.  However,
> automake: this behaviour will change in future Automake versions: they
> will
> automake: unconditionally cause object files to be placed in the same subdirectory
> automake: of the corresponding sources.
> automake: You are advised to start using 'subdir-objects' option throughout your
> automake: project, to avoid future incompatibilities.
>
> I think it's best for the relevant maintainers to add subdir-objects
> and do any other associated Makefile.am changes needed.  In some cases
> the paths in the warnings involved ../; I don't know if that adds any
> extra complications to the use of subdir-objects.

I'm not an automake expert, but I hope to be able to figure out
what is needed.  If not, I guess I'll just ask :-)

What is the plan for the previous branches?  Currently, it is necessary
to keep around a special version of automake etc for
--enable-maintainer-mode to work.  Backporting a patch which
involves regeneration of files in libgfortran/generated from
the files in libgfortan/m4 would then require keeping two versions
of the relevant tools around, and switching between them.

Would it make sense to backport because of this?

Thanks for your efforts!

Regards

        Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Update GCC to autoconf 2.69, automake 1.15.1

Janne Blomqvist-3
On Wed, Oct 31, 2018 at 9:12 AM Thomas Koenig <[hidden email]> wrote:

> > Makefile.am:48: warning: source file 'caf/single.c' is in a subdirectory,
> > Makefile.am:48: but option 'subdir-objects' is disabled
> > automake: warning: possible forward-incompatibility.
> > automake: At least a source file is in a subdirectory, but the
> 'subdir-objects'
> > automake: automake option hasn't been enabled.  For now, the
> corresponding output
> > automake: object file(s) will be placed in the top-level directory.
> However,
> > automake: this behaviour will change in future Automake versions: they
> > will
> > automake: unconditionally cause object files to be placed in the same
> subdirectory
> > automake: of the corresponding sources.
> > automake: You are advised to start using 'subdir-objects' option
> throughout your
> > automake: project, to avoid future incompatibilities.
> >
> > I think it's best for the relevant maintainers to add subdir-objects
> > and do any other associated Makefile.am changes needed.  In some cases
> > the paths in the warnings involved ../; I don't know if that adds any
> > extra complications to the use of subdir-objects.
>
> I'm not an automake expert, but I hope to be able to figure out
> what is needed.  If not, I guess I'll just ask :-)
>

My understanding is that we need to add 'subdir-objects' to
AM_INIT_AUTOMAKE in configure.ac.

See e.g. https://autotools.io/automake/options.html

(that site is pretty good for describing 'best practices' for modern
autotools; there's unfortunately a lot of very outdated autotools tutorials
around)

What is the plan for the previous branches?  Currently, it is necessary
> to keep around a special version of automake etc for
> --enable-maintainer-mode to work.  Backporting a patch which
> involves regeneration of files in libgfortran/generated from
> the files in libgfortan/m4 would then require keeping two versions
> of the relevant tools around, and switching between them.
>
> Would it make sense to backport because of this?
>

+1


--
Janne Blomqvist
Reply | Threaded
Open this post in threaded view
|

Re: Update GCC to autoconf 2.69, automake 1.15.1

Richard Biener-2
In reply to this post by Thomas Koenig-6
On Wed, Oct 31, 2018 at 8:12 AM Thomas Koenig <[hidden email]> wrote:

>
> Am 31.10.18 um 04:26 schrieb Joseph Myers:
> > This patch (diffs to generated files omitted below) updates GCC to use
> > autoconf 2.69 and automake 1.15.1.
>
> I think this should fix PR 82856.  Maybe you could confirm that this
> restores automake functionality with perl 5.6.26, and mention the PR
> in the ChangeLog.
>
> >
> > Makefile.am:48: warning: source file 'caf/single.c' is in a subdirectory,
> > Makefile.am:48: but option 'subdir-objects' is disabled
> > automake: warning: possible forward-incompatibility.
> > automake: At least a source file is in a subdirectory, but the 'subdir-objects'
> > automake: automake option hasn't been enabled.  For now, the corresponding output
> > automake: object file(s) will be placed in the top-level directory.  However,
> > automake: this behaviour will change in future Automake versions: they
> > will
> > automake: unconditionally cause object files to be placed in the same subdirectory
> > automake: of the corresponding sources.
> > automake: You are advised to start using 'subdir-objects' option throughout your
> > automake: project, to avoid future incompatibilities.
> >
> > I think it's best for the relevant maintainers to add subdir-objects
> > and do any other associated Makefile.am changes needed.  In some cases
> > the paths in the warnings involved ../; I don't know if that adds any
> > extra complications to the use of subdir-objects.
>
> I'm not an automake expert, but I hope to be able to figure out
> what is needed.  If not, I guess I'll just ask :-)
>
> What is the plan for the previous branches?  Currently, it is necessary
> to keep around a special version of automake etc for
> --enable-maintainer-mode to work.  Backporting a patch which
> involves regeneration of files in libgfortran/generated from
> the files in libgfortan/m4 would then require keeping two versions
> of the relevant tools around, and switching between them.

Does the regeneration really involve the automake/autoconf part
or would it be feasible to decouple it from --enable-maintainer-mode?

> Would it make sense to backport because of this?

I don't think so.

Richard.

> Thanks for your efforts!
>
> Regards
>
>         Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Update GCC to autoconf 2.69, automake 1.15.1

Ian Lance Taylor-4
In reply to this post by Thomas Koenig-6
On Tue, Oct 30, 2018 at 8:26 PM, Joseph Myers <[hidden email]> wrote:
>
> This patch (diffs to generated files omitted below) updates GCC to use
> autoconf 2.69 and automake 1.15.1.  (That's not the latest automake
> version, but it's the one used by binutils-gdb, with which consistency
> is desirable, and in any case seems a useful incremental update that
> should make a future update to 1.16.1 easier.)

Thanks for doing this.  As usual, please skip the patch to the libgo
directory; I'll commit that myself.  The patch to gotools is fine to
commit any time you are ready.

Ian
Reply | Threaded
Open this post in threaded view
|

Re: Update GCC to autoconf 2.69, automake 1.15.1

Joseph Myers
In reply to this post by Thomas Koenig-6
On Wed, 31 Oct 2018, Simon Marchi wrote:

> On 2018-10-30 11:26 p.m., Joseph Myers wrote:
> > This patch (diffs to generated files omitted below) updates GCC to use
> > autoconf 2.69 and automake 1.15.1.  (That's not the latest automake
> > version, but it's the one used by binutils-gdb, with which consistency
> > is desirable, and in any case seems a useful incremental update that
> > should make a future update to 1.16.1 easier.)
>
> Whenever you feel like bumping gcc to 1.16.1, I can take care of binutils-gdb.

Before possibly doing that we should get shared files back in sync again.

I've just applied my changes to shared files (where they went beyond
yours) to binutils-gdb, and also merged a couple of other config/ changes
from GCC to binutils-gdb (and done the consequent configure regenerations
in libdecnumber and zlib).  There are also libiberty changes, and changes
to shared various top-level files, that need to be got back in sync.  I
haven't examined them in detail but it seems mostly to be changes on the
GCC side needing to be applied to binutils-gdb.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Update GCC to autoconf 2.69, automake 1.15.1

Joseph Myers
In reply to this post by Thomas Koenig-6
On Wed, 31 Oct 2018, Eric Gallager wrote:

> > Index: zlib/Makefile.am
> > ===================================================================
> > --- zlib/Makefile.am (revision 265631)
> > +++ zlib/Makefile.am (working copy)
> > @@ -1,6 +1,6 @@
> >  ## Process this file with automake to create Makefile.in.
> >
> > -AUTOMAKE_OPTIONS = 1.8 cygnus
> > +AUTOMAKE_OPTIONS = foreign
>
> To get the modern equivalent of "cygnus" you need not just the
> "foreign" option (which you already have), but also the "no-dist"
> option in AUTOMAKE_OPTIONS.

As this is code shared with binutils-gdb, I was copying the change made
there.  (Plus the include of $(top_srcdir)/../multilib.am because zlib can
be built as a target module in GCC.)

--
Joseph S. Myers
[hidden email]