Binutils, GDB, GCC and Automake's 'cygnus' option

Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

Hello.

I see that binutils, GCC and GDB still use the Automake's 'cygnus' option
in some of their makefiles:

  $ grep_cygnus() {
  >   grep -r 'cygnus' . \
  >    | perl -ne '/(^|[^@])cygnus($|(:!\.com\b))/ and print' \
  >    | grep -v '^[^:]*/Makefile\.in:'; \
  > }

  $ (cd ~/src/binutils && grep_cygnus) # BINUTILS
  ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
  ./binutils/doc/Makefile.am:AUTOMAKE_OPTIONS = cygnus
  ./etc/configure.texi:AUTOMAKE_OPTIONS = cygnus
  ./gas/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.8 cygnus

  $ (cd ~/src/gdb && grep_cygnus) # GDB
  ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
  ./etc/configure.info:     AUTOMAKE_OPTIONS = cygnus
  ./etc/configure.texi:AUTOMAKE_OPTIONS = cygnus

  $ (cd ~/src/gcc && grep_cygnus) # GCC
  ./zlib/Makefile.am:AUTOMAKE_OPTIONS = 1.8 cygnus

But this option is going to be deprecated in Automake 1.12.1 and removed in
Automake 1.13:

  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034>

I just wanted to give you this head-up so that you won't be unpleasantly
surprised by the change.  Note that the actual removal of the 'cygnus'
option won't take place until Automake 1.13, which will at best be
released five or six months from now (and probably later than that).

Best regards,
  Stefano

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Joseph S. Myers]

On Wed, 28 Mar 2012, Stefano Lattarini wrote:

> But this option is going to be deprecated in Automake 1.12.1 and removed in
> Automake 1.13:
> 
>   <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034>

That page isn't very helpful since it doesn't give the non-deprecated way 
to achieve each part of the effect of "cygnus", if still desired (I think 
avoiding info documentation being built in the source directory, so that 
builds could use a non-writable source directory, may have been one part).  
Is there better transition documentation somewhere?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

Hi Joseph, thanks for the feedback.

On 03/28/2012 01:24 PM, Joseph S. Myers wrote:
> On Wed, 28 Mar 2012, Stefano Lattarini wrote:
> 
>> But this option is going to be deprecated in Automake 1.12.1 and removed in
>> Automake 1.13:
>>
>>   <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11034>
> 
> That page isn't very helpful since it doesn't give the non-deprecated way 
> to achieve each part of the effect of "cygnus" if still desired
>
By reading this:

  <http://www.gnu.org/software/automake/manual/automake.html#Cygnus>

you can see how to emulate part of the 'cygnus' effects by other means.

However, it's also clear that it won't be possible to 100% emulate the effect
of cygnus with other options/hacks; in particular the second, fourth and last
points there:

  - texinfo.tex is not required if a Texinfo source file is specified. The
    assumption is that the file will be supplied, but in a place that
    Automake cannot find. This assumption is an artifact of how Cygnus
    packages are typically bundled.

  - Certain tools will be searched for in the build tree as well as in the
    user's PATH. These tools are runtest, expect, makeinfo and texi2dvi.

  - The check target doesn't depend on all.

will basically be impossible to emulate.

> (I think avoiding info documentation being built in the source directory,
> so that builds could use a non-writable source directory, may have been
> one part).
>
There is probably some hack to obtain this effect (it's tested in the testsuite
somewhere), but my opinion is that if you distribute the generated info files
you should also have them generated in the source directory, to avoid nasty
surprises (for a similar issue, involving yacc and lex, see automake bug#10852,
in particular messages <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852#14>
and <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852#15>).

> Is there better transition documentation somewhere?
>
Nope, but it would be a good idea to prepare it before starting to deprecate
the 'cygnus' option.  Maybe even for 1.12.  Thanks for the suggestion.

Regards,
  Stefano

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Joseph S. Myers]

On Wed, 28 Mar 2012, Stefano Lattarini wrote:

>   - texinfo.tex is not required if a Texinfo source file is specified. The
>     assumption is that the file will be supplied, but in a place that
>     Automake cannot find. This assumption is an artifact of how Cygnus
>     packages are typically bundled.

texinfo.tex is in a known location, but only a single copy for GDB and 
binutils and a single copy for GCC rather than in each directory needing 
it.  Is the approach used (for example) in libquadmath/Makefile.am

TEXINFO_TEX   = ../gcc/doc/include/texinfo.tex

considered a suitable approach for this case?

>   - Certain tools will be searched for in the build tree as well as in the
>     user's PATH. These tools are runtest, expect, makeinfo and texi2dvi.

I did previously suggest removing the existing support for building and 
using these tools in-tree 
<http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01674.html>, but there was 
pushback on that.  I don't know, however, if it actually depends on 
anything built into automake.

>   - The check target doesn't depend on all.

I'm not aware of a need for that.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 03/28/2012 02:29 PM, Joseph S. Myers wrote:
> On Wed, 28 Mar 2012, Stefano Lattarini wrote:
> 
>>   - texinfo.tex is not required if a Texinfo source file is specified. The
>>     assumption is that the file will be supplied, but in a place that
>>     Automake cannot find. This assumption is an artifact of how Cygnus
>>     packages are typically bundled.
> 
> texinfo.tex is in a known location, but only a single copy for GDB and 
> binutils and a single copy for GCC rather than in each directory needing 
> it.
>
Which makes perfect sense.  So Automake should support this use case.

> Is the approach used (for example) in libquadmath/Makefile.am
> 
> TEXINFO_TEX   = ../gcc/doc/include/texinfo.tex
> 
> considered a suitable approach for this case?
>
This would seem the most sensible approach, yes.  Want to give it a try to
see whether it works in the GCC/GDB/Binutils tree? (What should be verified
particularly carefully is that the idiom works also in VPATH builds).

>>   - Certain tools will be searched for in the build tree as well as in the
>>     user's PATH. These tools are runtest, expect, makeinfo and texi2dvi.
> 
> I did previously suggest removing the existing support for building and 
> using these tools in-tree 
> <http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01674.html>, but there was 
> pushback on that.  I don't know, however, if it actually depends on 
> anything built into automake.
>
Hmm...  Couldn't the issues (if any) be worked around by explicitly
re-defining the $(EXPECT), $(RUNTEST), $(MAKEINFO) and $(TEXI2DVI)
variables in the relevant Makefiles so that they point to the bundled
tools?  E.g.,

  EXPECT = $(top_builddir)/../expect/expect

and so on.

>>   - The check target doesn't depend on all.
> 
> I'm not aware of a need for that.
> 
Glad to hear that.

Regards,
  Stefano

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Ian Lance Taylor]

Stefano Lattarini <stefano.lattarini@gmail.com> writes:

>> (I think avoiding info documentation being built in the source directory,
>> so that builds could use a non-writable source directory, may have been
>> one part).
>>
> There is probably some hack to obtain this effect (it's tested in the testsuite
> somewhere), but my opinion is that if you distribute the generated info files
> you should also have them generated in the source directory, to avoid nasty
> surprises (for a similar issue, involving yacc and lex, see automake bug#10852,
> in particular messages <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852#14>
> and <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852#15>).

It's important that it be possible to build with the sources on a
read-only disk.

It's useful to be able to include .info files in releases so that people
can build the releases without having to have makeinfo installed.

Ian

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

Hi Ian, Joseph, and sorry for the delay.

On 03/29/2012 01:43 AM, Ian Lance Taylor wrote:
> Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> 
>>> (I think avoiding info documentation being built in the source directory,
>>> so that builds could use a non-writable source directory, may have been
>>> one part).
>>>
>> There is probably some hack to obtain this effect (it's tested in the testsuite
>> somewhere), but my opinion is that if you distribute the generated info files
>> you should also have them generated in the source directory, to avoid nasty
>> surprises (for a similar issue, involving yacc and lex, see automake bug#10852,
>> in particular messages <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852#14>
>> and <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10852#15>).
> 
> It's useful to be able to include .info files in releases so that people
> can build the releases without having to have makeinfo installed.
>
I agree on this (as did past Automake maintainers -- in fact Automake distributes
generated info files be default).  But I also think that, whenever you distribute
generated files, the most sensible and safer thing to do is to have them generated
in the srcdir and not in the builddir, so that the tree from a VCS checkout and
the one extracted from a distribution tarball are similar and consistent (I held
a different opinion once, but Akim Demaille later changed my mind on this).

> It's important that it be possible to build with the sources on a
> read-only disk.
>
Yes, and in fact "make distcheck" verifies that this is possible.  However,
assuming it is also possible to *hack* a package with the sources on a read
only disk is not warranted.

In conclusion, I see two possible sane approaches w.r.t. the handling of
generated info files:

  - Have them distributed (automake's default).  This means that they will
    be build in the srcdir, not in the builddir: of course, this only affects
    the maintainer, since for a user that builds the package from a tarball
    those files should *not* be rebuilt, hence there is no problem even if
    the user's srcdir is read-only.

  - Don't distribute the generated info files.  To obtain this effect, it is
    enough to list the generated into files in the CLEANFILES variable (see
    for example the tests 'txinfo23', 'txinfo24' and 'txinfo25' in the automake
    testsuite).  In this case, the user will have to to have the 'makeinfo'
    program available to build them.

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Alfred M. Szmidt]

     - Have them distributed (automake's default).  This means that
       they will be build in the srcdir, not in the builddir: of
       course, this only affects the maintainer, since for a user that
       builds the package from a tarball those files should *not* be
       rebuilt, hence there is no problem even if the user's srcdir is
       read-only.

This has always been the right way to do things.

     - Don't distribute the generated info files.  [...]  In this
       case, the user will have to to have the 'makeinfo' program
       available to build them.

Please don't do this, it causes all kinds of headaches, like the small
fact that makeinfo will now be required to bootstrap.

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

Hi Alfred.

On 03/31/2012 11:08 AM, Alfred M. Szmidt wrote:
>      - Have them distributed (automake's default).  This means that
>        they will be build in the srcdir, not in the builddir: of
>        course, this only affects the maintainer, since for a user that
>        builds the package from a tarball those files should *not* be
>        rebuilt, hence there is no problem even if the user's srcdir is
>        read-only.
> 
> This has always been the right way to do things.
> 
>      - Don't distribute the generated info files.  [...]  In this
>        case, the user will have to to have the 'makeinfo' program
>        available to build them.
> 
> Please don't do this, it causes all kinds of headaches, like the small
> fact that makeinfo will now be required to bootstrap.
>
Note there's nothing I'm planning to do, nor I should do, in this regard:
the two setups described above are both already supported by the current
automake implementation (but the last one is not encouraged, even though
it makes perfect sense in some *rare* situations).  I was just pointing
out that you have to choose one of these setups -- so, if you want to
distribute info files, you must accept to have them build in the srcdir.

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Joseph S. Myers]

On Sat, 31 Mar 2012, Stefano Lattarini wrote:

> Note there's nothing I'm planning to do, nor I should do, in this regard:
> the two setups described above are both already supported by the current
> automake implementation (but the last one is not encouraged, even though
> it makes perfect sense in some *rare* situations).  I was just pointing
> out that you have to choose one of these setups -- so, if you want to
> distribute info files, you must accept to have them build in the srcdir.

The approach used in GCC, for example in the libquadmath directory, is a 
--enable-generated-files-in-srcdir configure option that is used when 
building a release tarball - so normally the files go in the build 
directory, but a special configuration is used to put them in the source 
directory only when building releases.  (This does not involve the 
"cygnus" option.)  I think support for that seems more generically useful 
(and it makes sense to me for automake to look at features used in other 
packages' configure/build systems, that aren't inherently specific to 
those packages, and try to provide generic versions of them).

The Binutils/GDB release tarball building process is substantially 
different and I'm not familiar with it.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/04/2012 03:17 PM, Joseph S. Myers wrote:
> On Sat, 31 Mar 2012, Stefano Lattarini wrote:
> 
>> Note there's nothing I'm planning to do, nor I should do, in this regard:
>> the two setups described above are both already supported by the current
>> automake implementation (but the last one is not encouraged, even though
>> it makes perfect sense in some *rare* situations).  I was just pointing
>> out that you have to choose one of these setups -- so, if you want to
>> distribute info files, you must accept to have them build in the srcdir.
> 
> The approach used in GCC, for example in the libquadmath directory, is a 
> --enable-generated-files-in-srcdir configure option that is used when 
> building a release tarball - so normally the files go in the build 
> directory, but a special configuration is used to put them in the source 
> directory only when building releases.  (This does not involve the 
> "cygnus" option.)  I think support for that seems more generically useful 
> (and it makes sense to me for automake to look at features used in other 
> packages' configure/build systems, that aren't inherently specific to 
> those packages, and try to provide generic versions of them).
>
I agree, but for the moment being I'm just interested in ensuring the
removal of the 'cygnus' option won't impact too negatively on its last
relevant users (GCC, GDB, Binutils, and the bfd library).  So far it
appears this is the case luckily, so I'll go ahead with the deprecation
of 'cygnus' in Automake 1.12.1 and its removal in Automake 1.13.

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

>>>>> "Stefano" == Stefano Lattarini <stefano.lattarini@gmail.com> writes:

Stefano> Note there's nothing I'm planning to do, nor I should do, in
Stefano> this regard: the two setups described above are both already
Stefano> supported by the current automake implementation (but the last
Stefano> one is not encouraged, even though it makes perfect sense in
Stefano> some *rare* situations).  I was just pointing out that you have
Stefano> to choose one of these setups -- so, if you want to distribute
Stefano> info files, you must accept to have them build in the srcdir.

Or we can just stick with an older version of automake.
It seems to me that this is the sensible approach.

Or move to some other build system; either autogen-based or just
requiring GNU make features.  The latter is fine for GCC but I'm not
sure whether all the src projects are on board.

I'm pretty disappointed that automake would make this change.  I realize
these choices may (arguably) make the most sense for most projects, but
the gcc and src trees are not like most projects; and really the whole
'cygnus' feature is there just to support these two big users.

Tom

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/02/2012 04:25 PM, Tom Tromey wrote:
>>>>>> "Stefano" == Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> 
> Stefano> Note there's nothing I'm planning to do, nor I should do, in
> Stefano> this regard: the two setups described above are both already
> Stefano> supported by the current automake implementation (but the last
> Stefano> one is not encouraged, even though it makes perfect sense in
> Stefano> some *rare* situations).  I was just pointing out that you have
> Stefano> to choose one of these setups -- so, if you want to distribute
> Stefano> info files, you must accept to have them build in the srcdir.
> 
> Or we can just stick with an older version of automake.
> It seems to me that this is the sensible approach.
>
> Or move to some other build system; either autogen-based or just
> requiring GNU make features.
>
<shameless plug>

  In this later case, you might want to take a look at the Automake-NG fork,
  started by myself (and still in a VERY early stage):

   - https://lists.gnu.org/mailman/listinfo/automake-ng

  Fork which will possibly be the subject of the oncoming Google summer of
  code:

   - http://www.gnu.org/software/soc-projects/ideas-2012.html#automake

</shameless plug>

> The latter is fine for GCC but I'm not sure whether all the src projects
> are on board.
> 
> I'm pretty disappointed that automake would make this change.  I realize
> these choices may (arguably) make the most sense for most projects, but
> the gcc and src trees are not like most projects; and really the whole
> 'cygnus' feature is there just to support these two big users.
>
True, and that was even stated in the manual; the whole point of ditching
support for cygnus trees is that by now those two big users are basically
not making any real use of the 'cygnus' option anymore.  To quote my
previous report:

    And as of today, almost any use of the 'cygnus' option has disappeared
    from the GCC and GDB trees; for example, the command:

      grep cygnus `find -name '*configure*' -o -name '*[Mm]akefile*' \
                        -o -name '*.am' -o -name '*.mk'`

    yields this in the GCC tree:

      ./zlib/Makefile.am:AUTOMAKE_OPTIONS = 1.8 cygnus
      ./zlib/Makefile.in:AUTOMAKE_OPTIONS = 1.8 cygnus

    and this in the GDB tree:

      ./bfd/doc/Makefile.in:AUTOMAKE_OPTIONS = 1.9 cygnus
      ./bfd/doc/Makefile.in:# cygnus option.
      ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
      ./bfd/doc/Makefile.am:# cygnus option.
      ./etc/configure.texi:option of @file{/usr/cygnus/@var{release}}, where @var{release} is the
      ./etc/configure.texi:@file{/usr/cygnus/@var{release}/H-@var{host}}, where @var{host} is the
      ./etc/configure.texi:AUTOMAKE_OPTIONS = cygnus
      ./etc/configure.texi:AUTOMAKE_OPTIONS = cygnus 1.3
      ./etc/configure.texi:@cindex canadian cross in cygnus tree
      ./etc/configure.texi:@cindex cygnus configure

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

>>>>> "Stefano" == Stefano Lattarini <stefano.lattarini@gmail.com> writes:

Stefano> True, and that was even stated in the manual; the whole point
Stefano> of ditching support for cygnus trees is that by now those two
Stefano> big users are basically not making any real use of the 'cygnus'
Stefano> option anymore.  To quote my previous report:

Stefano>       ./bfd/doc/Makefile.in:AUTOMAKE_OPTIONS = 1.9 cygnus
Stefano>       ./bfd/doc/Makefile.in:# cygnus option.
Stefano>       ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
Stefano>       ./bfd/doc/Makefile.am:# cygnus option.

But this is a reason not to remove it; or at least to restore the
previous handling of info files.

I don't care about the cygnus option per se.  It was always a grab bag
of hacks.  The issue is removing a feature that an important user relies
on.  So far the suggested replacements haven't seemed that good to me.

Tom

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/02/2012 05:16 PM, Tom Tromey wrote:
>>>>>> "Stefano" == Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> 
> Stefano> True, and that was even stated in the manual; the whole point
> Stefano> of ditching support for cygnus trees is that by now those two
> Stefano> big users are basically not making any real use of the 'cygnus'
> Stefano> option anymore.  To quote my previous report:
> 
> Stefano>       ./bfd/doc/Makefile.in:AUTOMAKE_OPTIONS = 1.9 cygnus
> Stefano>       ./bfd/doc/Makefile.in:# cygnus option.
> Stefano>       ./bfd/doc/Makefile.am:AUTOMAKE_OPTIONS = 1.9 cygnus
> Stefano>       ./bfd/doc/Makefile.am:# cygnus option.
> 
> But this is a reason not to remove it; or at least to restore the
> previous handling of info files.
>
> I don't care about the cygnus option per se.  It was always a grab bag
> of hacks.
>
And it's the hacks I'd like to remove, not the option per se :-)

> The issue is removing a feature that an important user relies on.
> So far the suggested replacements haven't seemed that good to me.
>
Sorry if I sound dense, but what exactly is the feature you are talking
about here?

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

>>>>> "Stefano" == Stefano Lattarini <stefano.lattarini@gmail.com> writes:

Stefano> Sorry if I sound dense, but what exactly is the feature you are
Stefano> talking about here?

I was under the impression that it would no longer be possible to build
info files in the build tree.  But, I see that, according to the
Automake manual, I am wrong about that.  So, sorry for the noise.

Tom

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/02/2012 09:36 PM, Tom Tromey wrote:
>>>>>> "Stefano" == Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> 
> Stefano> Sorry if I sound dense, but what exactly is the feature you are
> Stefano> talking about here?
> 
> I was under the impression that it would no longer be possible to build
> info files in the build tree.
>
It should still be possible, with the right hack (which is tested in the
testsuite, and required by other packages anyway).  The baseline is: if
you don't want your '.info' files to be distributed, then it should be
easily possible to have them built in the builddir; but if you want them
distributed, they will be built in the srcdir.  The rationale to do so is
to ensure that, in both cases, the developer's tree layout (as bootstrapped
from a VCS checkout) will match the user's tree layout (as obtained from a
distribution tarball).

> But, I see that, according to the Automake manual, I am wrong about that.
>
Weird, I didn't expect that hack to be documented in the manual...  And in
fact I cannot find it.  Could you please point me to it?  Thanks.

> So, sorry for the noise.
> 
Well, better safe than sorry :-)

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

>>>>> "Stefano" == Stefano Lattarini <stefano.lattarini@gmail.com> writes:

Stefano> It should still be possible, with the right hack (which is
Stefano> tested in the testsuite, and required by other packages
Stefano> anyway).  The baseline is: if you don't want your '.info' files
Stefano> to be distributed, then it should be easily possible to have
Stefano> them built in the builddir; but if you want them distributed,
Stefano> they will be built in the srcdir.

Now I am confused.  Is it possible to continue to work the way it does
today, or not?

If so, then great.

If not, then we need some other plan.

Tom> But, I see that, according to the Automake manual, I am wrong about that.

Stefano> Weird, I didn't expect that hack to be documented in the
Stefano> manual...  And in fact I cannot find it.  Could you please
Stefano> point me to it?  Thanks.

    http://www.gnu.org/software/automake/manual/automake.html#Cygnus

"Info files are always created in the build directory, and not in the
source directory. Packages that don't use the cygnus option can emulate
this effect by using the no-installinfo option and listing the generated
info files in the CLEANFILES variable. "

Re-reading the suggestion here, I can't understand how it would work.

Anyway the real use in the src tree is different, IIUC.
Info files are built in the build tree by developers, but put in the
source tree for distribution.

Tom

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/02/2012 10:19 PM, Tom Tromey wrote:
>>>>>> "Stefano" == Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> 
> Stefano> It should still be possible, with the right hack (which is
> Stefano> tested in the testsuite, and required by other packages
> Stefano> anyway).  The baseline is: if you don't want your '.info' files
> Stefano> to be distributed, then it should be easily possible to have
> Stefano> them built in the builddir; but if you want them distributed,
> Stefano> they will be built in the srcdir.
> 
> Now I am confused.  Is it possible to continue to work the way it does
> today, or not?
>
The point is: if you want to have info files build in the builddir *and*
distributed, than no, it won't be possible (without bending over backwards).
But I still don't understand why it's a big deal to have the '.info' files
placed in the srcdir *if you are going do distribute them*.

> If so, then great.
> 
> If not, then we need some other plan.
>
By looking at the 'handle_texinfo_helper' function in the automake script,
I suspect adding a new Automake option 'info-in-builddir' (say) and an
handful of lines to the automake script might be enough to give you an easy
way to force the '.info' files to be generated in the builddir.  But before
doing so, I'd like to understand why you want so strongly to support such
a setup.

> Tom> But, I see that, according to the Automake manual, I am wrong about that.
> 
> Stefano> Weird, I didn't expect that hack to be documented in the
> Stefano> manual...  And in fact I cannot find it.  Could you please
> Stefano> point me to it?  Thanks.
> 
>     http://www.gnu.org/software/automake/manual/automake.html#Cygnus
> 
> "Info files are always created in the build directory, and not in the
> source directory. Packages that don't use the cygnus option can emulate
> this effect by using the no-installinfo option and listing the generated
> info files in the CLEANFILES variable. "
> 
> Re-reading the suggestion here, I can't understand how it would work.
>
Another automake internal hack basically.  For more details, in case you are
interested, see code and comments in the 'automake.in:handle_texinfo_helper'
subroutine, and the test cases txinfo{23,24,25}.test in the Automake
distribution.

> Anyway the real use in the src tree is different, IIUC.
> Info files are built in the build tree by developers, but put in the
> source tree for distribution.
>
In such a setup, what is the issue with having the '.info' files built
in the srcdir?  It's not like the developers will develop with a
read-only source tree, right?

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Ian Lance Taylor]

Stefano Lattarini <stefano.lattarini@gmail.com> writes:

>> Anyway the real use in the src tree is different, IIUC.
>> Info files are built in the build tree by developers, but put in the
>> source tree for distribution.
>>
> In such a setup, what is the issue with having the '.info' files built
> in the srcdir?  It's not like the developers will develop with a
> read-only source tree, right?

There are many different people who build gcc from snapshots, not
releases, for various different reasons.  It would be good if those
people could continue to build from a read-only source directory.  It
would be good if those people could get .info files appropriate to their
source code.  Of course releases should continue to contain .info files.

We do not want .info files to be part of source code control for
development, but we do want them to be part of source code control for
releases.  That means that there is no correct setting for svn:ignore or
whatever.  This can be worked around, it's just a minor pain.

Ian

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

OK, you've all made clear you have your sensible reasons to have the '.info'
files generated in the builddir in your use cases.  Since the actual change
required by automake to allow this is very small and safe, I'm ready to do
it (see attached patch, which I will push in a couple of days to 'master' if
there is no objection).

But since I'm not yet ready to publish this new feature, I intend to make
it available only though the new, undocumented option named (literally)
"hack!info-in-builddir".  I hope this is acceptable to you.

Regards,
  Stefano

[-- Attachment #2: 0001-texinfo-hack-to-allow-.info-files-to-be-generated-in.patch --]
[-- Type: text/x-diff, Size: 6380 bytes --]

From de715b44d25ad523b558d7321ce87bcf8c0cdb09 Mon Sep 17 00:00:00 2001
Message-Id: <de715b44d25ad523b558d7321ce87bcf8c0cdb09.1333483415.git.stefano.lattarini@gmail.com>
From: Stefano Lattarini <stefano.lattarini@gmail.com>
Date: Tue, 3 Apr 2012 22:02:55 +0200
Subject: [PATCH] texinfo: hack to allow '.info' files to be generated in the
 builddir

The possibility to force the '.info' files to be generated in the
builddir rather than the srcdir is requested by the developers of
GCC, GDB, GNU binutils and the GNU bfd library.  The lack of such
a possibility being the last obstacle to the removal of the support
for Cygnus-style trees (for which such a setup for '.info' files
generation was automatically implied).

So allow the developers to have the '.info' files to be generated
in the builddir rather than the srcdir, through the use of the new
*undocumented* option '!hack!info-in-builddir' (whose name should
made it clear that it is not meant for public consumption).

See also the extensive discussion about automake bug#11034.

* lib/Automake/Options.pm (_is_valid_easy_option): Recognize the
new option.
* automake.in (handle_texinfo_helper): If it's set, initialize
'$insrc' to '0', so that info files will be generated in the
builddir.  Adjust comments to match.
* tests/txinfo-builddir.test: New test.
* tests/list-of-tests.mk: Add it.

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
---
 automake.in                |   28 +++++++++++-----
 lib/Automake/Options.pm    |    1 +
 tests/list-of-tests.mk     |    1 +
 tests/txinfo-builddir.test |   74 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 95 insertions(+), 9 deletions(-)
 create mode 100755 tests/txinfo-builddir.test

diff --git a/automake.in b/automake.in
index f96e36b..b793a12 100644
--- a/automake.in
+++ b/automake.in
@@ -3278,15 +3278,25 @@ sub handle_texinfo_helper ($)
       # have a single variable ($INSRC) that controls whether
       # the current .info file must be built in the source tree
       # or in the build tree.  Actually this variable is switched
-      # off for .info files that appear to be cleaned; this is
-      # for backward compatibility with package such as Texinfo,
-      # which do things like
-      #   info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
-      #   DISTCLEANFILES = texinfo texinfo-* info*.info*
-      #   # Do not create info files for distribution.
-      #   dist-info:
-      # in order not to distribute .info files.
-      my $insrc = ($out_file =~ $user_cleaned_files) ? 0 : 1;
+      # off in two cases:
+      #  (1) For '.info' files that appear to be cleaned; this is for
+      #      backward compatibility with package such as Texinfo,
+      #      which do things like
+      #        info_TEXINFOS = texinfo.txi info-stnd.texi info.texi
+      #        DISTCLEANFILES = texinfo texinfo-* info*.info*
+      #        # Do not create info files for distribution.
+      #        dist-info:
+      #      in order not to distribute .info files.
+      #  (2) When the undocumented option '!hack!info-in-builddir'
+      #      is given.  This is done to allow the developers of
+      #      GCC, GDB, GNU binutils and the GNU bfd library to force
+      #      force the '.info' files to be generated in the builddir
+      #      rather than the srcdir, as was once done when the (now
+      #      obsolete) 'cygnus' option was given.  See automake
+      #      bug#11034 for more discussion.
+      my $insrc = 1;
+      $insrc = 0 if $out_file =~ $user_cleaned_files;
+      $insrc = 0 if option '!hack!info-in-builddir';
 
       my $soutdir = '$(srcdir)/' . $outdir;
       $outdir = $soutdir if $insrc;
diff --git a/lib/Automake/Options.pm b/lib/Automake/Options.pm
index 2f977bd..ee33837 100644
--- a/lib/Automake/Options.pm
+++ b/lib/Automake/Options.pm
@@ -267,6 +267,7 @@ sub _is_valid_easy_option ($)
 {
   my $opt = shift;
   return scalar grep { $opt eq $_ } qw(
+    !hack!info-in-builddir
     check-news
     color-tests
     cygnus
diff --git a/tests/list-of-tests.mk b/tests/list-of-tests.mk
index de022a2..fa57ce5 100644
--- a/tests/list-of-tests.mk
+++ b/tests/list-of-tests.mk
@@ -1181,6 +1181,7 @@ txinfo31.test \
 txinfo32.test \
 txinfo33.test \
 txinfo-unrecognized-extension.test \
+txinfo-builddir.test \
 transform.test \
 transform2.test \
 transform3.test \
diff --git a/tests/txinfo-builddir.test b/tests/txinfo-builddir.test
new file mode 100755
index 0000000..64ca190
--- /dev/null
+++ b/tests/txinfo-builddir.test
@@ -0,0 +1,74 @@
+#! /bin/sh
+# Copyright (C) 2012 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2, or (at your option)
+# any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# Check that info files are built in builddir when needed.
+# This test that this can be done through the "magic" undocumented
+# option '!hack!info-in-builddir', as requested by at least GCC, GDB,
+# GNU binutils and the GNU bfd library.  See automake bug#11034.
+
+# See also txinfo23.test, txinfo24.test, txinfo25.test.
+
+required=makeinfo
+. ./defs || Exit 1
+
+echo AC_OUTPUT >> configure.ac
+
+cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = cygnus ##!hack!info-in-builddir
+info_TEXINFOS = foo.texi subdir/bar.texi
+subdir_bar_TEXINFOS = subdir/inc.texi
+END
+
+mkdir subdir
+
+cat > foo.texi << 'END'
+\input texinfo
+@setfilename foo.info
+@settitle foo
+@node Top
+Hello walls.
+@include version.texi
+@bye
+END
+
+cat > subdir/bar.texi << 'END'
+\input texinfo
+@setfilename bar.info
+@settitle bar
+@node Top
+Hello walls.
+@include inc.texi
+@bye
+END
+
+cat > subdir/inc.texi << 'END'
+I'm included.
+END
+
+$ACLOCAL
+$AUTOMAKE --add-missing
+$AUTOCONF
+
+mkdir build
+cd build
+../configure
+$MAKE info
+test -f foo.info
+test -f subdir/bar.info
+test ! -f ../foo.info
+test ! -f ../subdir/bar.info
+
+:
-- 
1.7.9

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/03/2012 10:04 PM, Stefano Lattarini wrote:
> OK, you've all made clear you have your sensible reasons to have the '.info'
> files generated in the builddir in your use cases.  Since the actual change
> required by automake to allow this is very small and safe, I'm ready to do
> it (see attached patch, which I will push in a couple of days to 'master' if
> there is no objection).
> 
> But since I'm not yet ready to publish this new feature, I intend to make
> it available only though the new, undocumented option named (literally)
> "hack!info-in-builddir".  I hope this is acceptable to you.
> 
Oops, with this squashed in:

  diff --git a/tests/txinfo-builddir.test b/tests/txinfo-builddir.test
  index 64ca190..a09af80 100755
  --- a/tests/txinfo-builddir.test
  +++ b/tests/txinfo-builddir.test
  @@ -27,7 +27,7 @@ required=makeinfo
   echo AC_OUTPUT >> configure.ac

   cat > Makefile.am << 'END'
  -AUTOMAKE_OPTIONS = cygnus ##!hack!info-in-builddir
  +AUTOMAKE_OPTIONS = !hack!info-in-builddir
   info_TEXINFOS = foo.texi subdir/bar.texi
   subdir_bar_TEXINFOS = subdir/inc.texi
   END

Sorry for the noise,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]

On 04/03/2012 10:05 PM, Stefano Lattarini wrote:
> On 04/03/2012 10:04 PM, Stefano Lattarini wrote:
>> OK, you've all made clear you have your sensible reasons to have the '.info'
>> files generated in the builddir in your use cases.  Since the actual change
>> required by automake to allow this is very small and safe, I'm ready to do
>> it (see attached patch, which I will push in a couple of days to 'master' if
>> there is no objection).
>>
>> But since I'm not yet ready to publish this new feature, I intend to make
>> it available only though the new, undocumented option named (literally)
>> "hack!info-in-builddir".  I hope this is acceptable to you.
>>
On a second though, by double-checking the existing code, I couldn't see how
the 'cygnus' option could possibly influence the location of the generated
info files -- and it turned out it didn't!  Despite what was documented in
the manual, the 'cygnus' option did *not* cause the generated '.info' files
to be placed in the builddir (see attached test case).  This is true for at
least for automake 1.9.6, 1.10.3, 1.11.1, 1.11.4, and automake built from
the master branch (I've checked them all).  Since nobody ever complained
about such a breakage, I conclude that the feature was not truly needed, and
I'm thus withdrawing my previous patch.

Regards,
  Stefano

[-- Attachment #2: txinfo-cygnus-bug.test --]
[-- Type: text/plain, Size: 1224 bytes --]

#! /bin/sh
# Copyright (C) 2012 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

# The cygnus option do not really cause the '.info' files to be
# generated in the builddir!

required=makeinfo
. ./defs || Exit 1

cat >> configure.ac <<END
AM_MAINTAINER_MODE
AC_OUTPUT
END

cat > Makefile.am << 'END'
AUTOMAKE_OPTIONS = cygnus -Wno-override
info_TEXINFOS = foo.texi
END

cat > foo.texi << 'END'
\input texinfo
@setfilename foo.info
@settitle foo
@node Top
Hello walls.
@bye
END

$ACLOCAL
$AUTOMAKE --add-missing
$AUTOCONF

mkdir build
cd build
../configure
$MAKE info
ls -l . ..
test -f foo.info
test ! -f ../foo.info

:

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Tom Tromey]

>>>>> "Stefano" == Stefano Lattarini <stefano.lattarini@gmail.com> writes:

Stefano> On a second though, by double-checking the existing code, I
Stefano> couldn't see how the 'cygnus' option could possibly influence
Stefano> the location of the generated info files -- and it turned out
Stefano> it didn't!  Despite what was documented in the manual, the
Stefano> 'cygnus' option did *not* cause the generated '.info' files to
Stefano> be placed in the builddir (see attached test case).

It certainly does for me:

    barimba. pwd
    /home/tromey/gnu/baseline-gdb/build/binutils
    barimba. grep '^srcdir = ' Makefile
    srcdir = ../../src/binutils
    barimba. find . -name 'binutils.info'
    ./doc/binutils.info
    barimba. find ../../src/binutils -name 'binutils.info'
    barimba.

How did you test it?
If you built from a distribution tar, then it is expected that the info
file would be in srcdir.

Tom

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/03/2012 10:39 PM, Tom Tromey wrote:
>>>>>> "Stefano" == Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> 
> Stefano> On a second though, by double-checking the existing code, I
> Stefano> couldn't see how the 'cygnus' option could possibly influence
> Stefano> the location of the generated info files -- and it turned out
> Stefano> it didn't!  Despite what was documented in the manual, the
> Stefano> 'cygnus' option did *not* cause the generated '.info' files to
> Stefano> be placed in the builddir (see attached test case).
> 
> It certainly does for me:
>
Yes, but (at least for the binutils case) that's only because you already
have an hack *unrelated to the cygnus option* to make it work; i.e., in
'binutils/doc/Makefile.am', I read:

  # Automake 1.9 will only build info files in the objdir if they are
  # mentioned in DISTCLEANFILES.  It doesn't have to be unconditional,
  # though, so we use a bogus condition.
  if GENINSRC_NEVER
  DISTCLEANFILES = binutils.info
  endif

>     barimba. pwd
>     /home/tromey/gnu/baseline-gdb/build/binutils
>     barimba. grep '^srcdir = ' Makefile
>     srcdir = ../../src/binutils
>     barimba. find . -name 'binutils.info'
>     ./doc/binutils.info
>     barimba. find ../../src/binutils -name 'binutils.info'
>     barimba.
> 
> How did you test it?
>
With the testcase attached to my mail (warning: it requires the Automake
testsuite infrastructure to work).  I can transform it in an independent
test script if you are really interested.

> If you built from a distribution tar, then it is expected that the info
> file would be in srcdir.
>
I didn't use the binutils distribution to test my claim, but the minimal
test case I had created on purpose, and attached in the previous mail.

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Ian Lance Taylor]

Stefano Lattarini <stefano.lattarini@gmail.com> writes:

> But since I'm not yet ready to publish this new feature, I intend to make
> it available only though the new, undocumented option named (literally)
> "hack!info-in-builddir".  I hope this is acceptable to you.

Sure, works for me.

Thanks.

Ian

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Pedro Alves]

On 04/03/2012 09:04 PM, Stefano Lattarini wrote:

> OK, you've all made clear you have your sensible reasons to have the '.info'

...
> it available only though the new, undocumented option named (literally)
> "hack!info-in-builddir".  I hope this is acceptable to you.
...
> *undocumented* option '!hack!info-in-builddir' (whose name should
> made it clear that it is not meant for public consumption).

So will this be called a hack forever, or will the naming be revisited
before a release?  IMO, either the feature is sensible, and there doesn't
seem to be a good reason other users couldn't also use it, and hence it
should get a non-hackish name and be documented; or it isn't sensible, and
then it shouldn't exist.  Why the second-class treatment?

-- 
Pedro Alves

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Miles Bader]

Pedro Alves <palves@redhat.com> writes:
>> OK, you've all made clear you have your sensible reasons to have the '.info'
>
> ...
>> it available only though the new, undocumented option named (literally)
>> "hack!info-in-builddir".  I hope this is acceptable to you.
> ...
>> *undocumented* option '!hack!info-in-builddir' (whose name should
>> made it clear that it is not meant for public consumption).
>
> So will this be called a hack forever, or will the naming be revisited
> before a release?  IMO, either the feature is sensible, and there doesn't
> seem to be a good reason other users couldn't also use it, and hence it
> should get a non-hackish name and be documented; or it isn't sensible, and
> then it shouldn't exist.  Why the second-class treatment?

I suspect there are better, cleaner, ways to accomplish the underlying
goal, but I suppose the gcc maintainers don't want to spend the time
fiddling around with their build infrastructure for such a minor
issue...

-miles

-- 
Alone, adj. In bad company.

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 04/04/2012 01:53 AM, Miles Bader wrote:
> Pedro Alves <palves@redhat.com> writes:
>>> OK, you've all made clear you have your sensible reasons to have the '.info'
>>
>> ...
>>> it available only though the new, undocumented option named (literally)
>>> "hack!info-in-builddir".  I hope this is acceptable to you.
>> ...
>>> *undocumented* option '!hack!info-in-builddir' (whose name should
>>> made it clear that it is not meant for public consumption).
>>
>> So will this be called a hack forever, or will the naming be revisited
>> before a release?  IMO, either the feature is sensible, and there doesn't
>> seem to be a good reason other users couldn't also use it, and hence it
>> should get a non-hackish name and be documented; or it isn't sensible, and
>> then it shouldn't exist.  Why the second-class treatment?
> 
> I suspect there are better, cleaner, ways to accomplish the underlying
> goal, but I suppose the gcc maintainers don't want to spend the time
> fiddling around with their build infrastructure for such a minor
> issue...
>
Exactly; basically, I wrote the proposed hack because the Binutils, GDB and
GCC packages are important enough that is worth to cater for their unusual
(or even maybe slightly broken) usages, even when that requires a little
extra work on the Automake part.

But then it turned out that the new hack is not really needed, since those
packages already have another hack in place to obtain the behaviour they
want (see my recent answer to Tom), and one that works also with older
Automake releases (back at least to Automake 1.9).

So I've retired my patch, and the hack it introduces.

Regards,
  Stefano

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Pedro Alves]

On 04/04/2012 12:53 AM, Miles Bader wrote:

> I suspect there are better, cleaner, ways to accomplish the underlying
> goal, but I suppose the gcc maintainers don't want to spend the time
> fiddling around with their build infrastructure for such a minor
> issue...


Why speculate?  I haven't seen any hint on what the better, cleaner,
way to accomplish this is.

-- 
Pedro Alves

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Joern Rennecke]

Quoting Stefano Lattarini <stefano.lattarini@gmail.com>:

> By looking at the 'handle_texinfo_helper' function in the automake script,
> I suspect adding a new Automake option 'info-in-builddir' (say) and an
> handful of lines to the automake script might be enough to give you an easy
> way to force the '.info' files to be generated in the builddir.  But before
> doing so, I'd like to understand why you want so strongly to support such
> a setup.

It is quite common during development / testing to build multiple
configurations simultaneously from the same sources, with separate
make processes.  Writing to the source directory would cause disastrous
race conditions.

Re: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

[-- Attachment #1: Type: text/plain, Size: 523 bytes --]

On 03/28/2012 02:19 PM, Stefano Lattarini wrote:
> Hi Joseph, thanks for the feedback.
> On 03/28/2012 01:24 PM, Joseph S. Myers wrote:
>>
>> Is there better transition documentation somewhere?
>>
> Nope, but it would be a good idea to prepare it before starting to deprecate
> the 'cygnus' option.  Maybe even for 1.12.  Thanks for the suggestion.
>
Or even for 1.11.4, which is to be released in two/three days.  What about the
attached patch?  I will push it by this evening if there is no objection.

Thanks,
  Stefano

[-- Attachment #2: 0001-docs-deprecate-cygnus-mode-help-the-transition.patch --]
[-- Type: text/x-diff, Size: 7049 bytes --]

From 5bb72934aa7d96e2faa90fa1c59c24f01e83c91f Mon Sep 17 00:00:00 2001
Message-Id: <5bb72934aa7d96e2faa90fa1c59c24f01e83c91f.1333193814.git.stefano.lattarini@gmail.com>
From: Stefano Lattarini <stefano.lattarini@gmail.com>
Date: Sat, 31 Mar 2012 11:04:41 +0200
Subject: [PATCH] docs: deprecate 'cygnus' mode, help the transition

Support for "Cygnus-style" trees (so far enabled by the 'cygnus'
option) will be deprecated in one release of the next major series
(1.12.x) and removed in the next major release after that (1.13).
Better to start warning about this in the manual.

* docs/automake.texi: Warn about the oncoming deprecation of the
'cygnus' mode.  Suggest some idioms that can be used to retain some
effects of the 'cygnus' option.
* THANKS: Update.

From a suggestion by Joseph S. Myers in automake bug#11034.

Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
---
 THANKS            |    1 +
 doc/automake.texi |   68 ++++++++++++++++++++++++++++-------------------------
 2 files changed, 37 insertions(+), 32 deletions(-)

diff --git a/THANKS b/THANKS
index 702c97b..a2091ab 100644
--- a/THANKS
+++ b/THANKS
@@ -178,6 +178,7 @@ John Ratliff		autoconf@technoplaza.net
 John R. Cary		cary@txcorp.com
 John W. Coomes		jcoomes@eng.Sun.COM
 Jonathan Nieder		jrnieder@gmail.com
+Joseph S. Myers		joseph@codesourcery.com
 Josh MacDonald		jmacd@cs.berkeley.edu
 Joshua Cowan		jcowan@jcowan.reslife.okstate.edu
 js pendry		js.pendry@msdw.com
diff --git a/doc/automake.texi b/doc/automake.texi
index 9b6b8f5..9da5fd9 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -117,7 +117,7 @@ section entitled ``GNU Free Documentation License.''
 * Conditionals::                Conditionals
 * Silencing Make::              Obtain less verbose output from @command{make}
 * Gnits::                       The effect of @option{--gnu} and @option{--gnits}
-* Cygnus::                      The effect of @option{--cygnus}
+* Cygnus::                      The effect of @option{--cygnus} (deprecated, soon to be removed)
 * Not Enough::                  When Automake is not Enough
 * Distributing::                Distributing the Makefile.in
 * API Versioning::              About compatibility between Automake versions
@@ -1943,10 +1943,13 @@ standard is actually published (which may never happen).
 @xref{Gnits}, for more information on the precise implications of the
 strictness level.
 
-Automake also has a special ``cygnus'' mode that is similar to
-strictness but handled differently.  This mode is useful for packages
-that are put into a ``Cygnus'' style tree (e.g., the GCC tree).
-@xref{Cygnus}, for more information on this mode.
+Automake also has a special (and @emph{today deprecated}) ``cygnus'' mode
+that is similar to strictness but handled differently.  This mode is
+useful for packages that are put into a ``Cygnus'' style tree (e.g., older
+versions of the GCC and gdb trees).  @xref{Cygnus}, for more information
+on this mode.  Please note that this mode is deprecated and @emph{will be
+removed in the future automake versions}; you must avoid its use in new
+packages, and should stop using it in existing packages as well.
 
 
 @node Uniform
@@ -2602,6 +2605,8 @@ copied.  The default is to make a symbolic link.
 @opindex --cygnus
 Causes the generated @file{Makefile.in}s to follow Cygnus rules, instead
 of GNU or Gnits rules.  For more information, see @ref{Cygnus}.
+Note that @emph{this mode of operation is deprecated, and will be removed}
+in a future Automake release.
 
 @item -f
 @opindex -f
@@ -10322,10 +10327,15 @@ The file @file{THANKS} is required.
 
 @cindex @option{cygnus} strictness
 
-Some packages, notably GNU GCC and GNU gdb, have a build environment
-originally written at Cygnus Support (subsequently renamed Cygnus
-Solutions, and then later purchased by Red Hat).  Packages with this
-ancestry are sometimes referred to as ``Cygnus'' trees.
+@emph{The features described in this section are deprecated; you must
+not use any of them in new code, and should remove their use from older
+but still maintained code: they will be withdrawn in a future Automake
+release.}
+
+Some packages, notably GNU GCC and GNU gdb, used to have a build
+environment originally written at Cygnus Support (subsequently renamed
+Cygnus Solutions, and then later purchased by Red Hat).  Packages with
+this ancestry are sometimes referred to as ``Cygnus'' trees.
 
 A Cygnus tree has slightly different rules for how a
 @file{Makefile.in} is to be constructed.  Passing @option{--cygnus} to
@@ -10336,44 +10346,38 @@ Here are the precise effects of @option{--cygnus}:
 
 @itemize @bullet
 @item
-Info files are always created in the build directory, and not in the
-source directory.
-
-@item
-@file{texinfo.tex} is not required if a Texinfo source file is
-specified.  The assumption is that the file will be supplied, but in a
-place that Automake cannot find.  This assumption is an artifact of how
-Cygnus packages are typically bundled.
+@option{--foreign} is implied.
 
 @item
-@samp{make dist} is not supported, and the rules for it are not
-generated.  Cygnus-style trees use their own distribution mechanism.
+The options @option{no-installinfo}, @option{no-dependencies} and
+@option{no-dist} are implied (@pxref{Options}).
 
 @item
-Certain tools will be searched for in the build tree as well as in the
-user's @env{PATH}.  These tools are @command{runtest}, @command{expect},
-@command{makeinfo} and @command{texi2dvi}.
+The macro @code{AM_MAINTAINER_MODE} is required.
 
 @item
-@option{--foreign} is implied.
+Info files are always created in the build directory, and not in the
+source directory.  Packages that don't use the @option{cygnus} option
+can emulate this effect by using the @option{no-installinfo} option
+and listing the generated info files in the @code{CLEANFILES} variable.
 
 @item
-The options @option{no-installinfo} and @option{no-dependencies} are
-implied.
+@file{texinfo.tex} is not required if a Texinfo source file is
+specified.  The assumption is that the file will be supplied, but in a
+place that Automake cannot find -- it is an artifact of how Cygnus
+packages are typically bundled.  This effect can be emulated in
+packages not using the @option{cygnus} option with a proper definition
+of the @code{TEXINFO_TEX} variable, @pxref{Texinfo}.
 
 @item
-The macro @code{AM_MAINTAINER_MODE} is required.
+Certain tools will be searched for in the build tree as well as in the
+user's @env{PATH}.  These tools are @command{runtest}, @command{expect},
+@command{makeinfo} and @command{texi2dvi}.
 
 @item
 The @code{check} target doesn't depend on @code{all}.
 @end itemize
 
-GNU maintainers are advised to use @option{gnu} strictness in preference
-to the special Cygnus mode.  Some day, perhaps, the differences between
-Cygnus trees and GNU trees will disappear (for instance, as GCC is made
-more standards compliant).  At that time the special Cygnus mode will be
-removed.
-
 
 @node Not Enough
 @chapter When Automake Isn't Enough
-- 
1.7.9

Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Stefano Lattarini]

On 03/31/2012 01:38 PM, Stefano Lattarini wrote:
> On 03/28/2012 02:19 PM, Stefano Lattarini wrote:
>> Hi Joseph, thanks for the feedback.
>> On 03/28/2012 01:24 PM, Joseph S. Myers wrote:
>>>
>>> Is there better transition documentation somewhere?
>>>
>> Nope, but it would be a good idea to prepare it before starting to deprecate
>> the 'cygnus' option.  Maybe even for 1.12.  Thanks for the suggestion.
>>
> Or even for 1.11.4, which is to be released in two/three days.  What about the
> attached patch?  I will push it by this evening if there is no objection.
> 
Applied to maint, merged into master and branch-1.11, and pushed.

Regards,
  Stefano