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

2012-03-31 Thread Stefano Lattarini
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
From 5bb72934aa7d96e2faa90fa1c59c24f01e83c91f Mon Sep 17 00:00:00 2001
Message-Id: 5bb72934aa7d96e2faa90fa1c59c24f01e83c91f.1333193814.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@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.lattar...@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		autoc...@technoplaza.net
 John R. Cary		c...@txcorp.com
 John W. Coomes		jcoo...@eng.sun.com
 Jonathan Nieder		jrnie...@gmail.com
+Joseph S. Myers		jos...@codesourcery.com
 Josh MacDonald		jm...@cs.berkeley.edu
 Joshua Cowan		jco...@jcowan.reslife.okstate.edu
 js pendry		js.pen...@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} 

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

2012-03-28 Thread 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
jos...@codesourcery.com



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

2012-03-28 Thread 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
jos...@codesourcery.com



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

2012-03-28 Thread 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

2012-03-28 Thread Ian Lance Taylor
Stefano Lattarini stefano.lattar...@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