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

[Stefano Lattarini]

On 04/03/2012 10:39 PM, Tom Tromey wrote:
>> "Stefano" == Stefano Lattarini  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

[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

[Stefano Lattarini]

On 04/04/2012 01:53 AM, Miles Bader wrote:
> Pedro Alves  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

[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
jos...@codesourcery.com

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

[Miles Bader]

Pedro Alves  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

[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

[Ian Lance Taylor]

Stefano Lattarini  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

[Tom Tromey]

> "Stefano" == Stefano Lattarini  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: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]

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
#! /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 .

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

required=makeinfo
. ./defs || Exit 1

cat >> configure.ac < 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

[Stefano Lattarini]

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
>From de715b44d25ad523b558d7321ce87bcf8c0cdb09 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Stefano Lattarini 
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 
---
 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 000..64ca190
--- /dev/null
+++ b/tests/txinfo-builddir.test
@@ -0,0 +1,74 @@
+#! /bin/sh
+# Copyright (C) 2012 Fre

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

[Joern Rennecke]

Quoting Stefano Lattarini :


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: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option

[Roumen Petrov]

Hi Stefano,

Stefano Lattarini wrote:

On 04/02/2012 10:19 PM, Tom Tromey wrote:

"Stefano" == Stefano Lattarini  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*.


A lot of manual include path to executable. This path depend from vendor 
and OS. The correctly written documentation has to use proper paths
For instance /bin/sh is correct for most system but on some linux based 
OS-es it is /system/bin/sh .


So the rule to put into source tree generated files (documentation) 
prevent parallel build for multiple host or target platforms.



[SNIP]
Roumen

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

[Ian Lance Taylor]

Stefano Lattarini  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]

On 04/02/2012 10:12 PM, Roumen Petrov wrote:
> Hi Stefano,
> 
> Stefano Lattarini wrote:
>> [SNIP]
>> 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.
> Sound like if user would like to distribute binaries they must be in source 
> directory .
> Why generated file, not required for build process, has to be places in 
> source tree.
>
This is explained in excruciating details in some code comments in the automake
script (in the 'handle_texinfo_helper', more precisely).  I'll just copy and
paste them here:

  #  Until Automake 1.6.3, .info files were built in the
  #  source tree.  This was an obstacle to the support of
  #  non-distributed .info files, and non-distributed .texi
  #  files.
  #
  #  * Non-distributed .texi files is important in some packages
  #where .texi files are built at make time, probably using
  #other binaries built in the package itself, maybe using
  #tools or information found on the build host.  Because
  #these files are not distributed they are always rebuilt
  #at make time; they should therefore not lie in the source
  #directory.  One plan was to support this using
  #nodist_info_TEXINFOS or something similar.  (Doing this
  #requires some sanity checks.  For instance Automake should
  #not allow:
  #  dist_info_TEXINFOS = foo.texi
  #  nodist_foo_TEXINFOS = included.texi
  #because a distributed file should never depend on a
  #non-distributed file.)
  #
  #  * If .texi files are not distributed, then .info files should
  #not be distributed either.  There are also cases where one
  #wants to distribute .texi files, but does not want to
  #distribute the .info files.  For instance the Texinfo package
  #distributes the tool used to build these files; it would
  #be a waste of space to distribute them.  It's not clear
  #which syntax we should use to indicate that .info files should
  #not be distributed.  Akim Demaille suggested that eventually
  #we switch to a new syntax:
  #|  Maybe we should take some inspiration from what's already
  #|  done in the rest of Automake.  Maybe there is too much
  #|  syntactic sugar here, and you want
  #| nodist_INFO = bar.info
  #| dist_bar_info_SOURCES = bar.texi
  #| bar_texi_DEPENDENCIES = foo.texi
  #|  with a bit of magic to have bar.info represent the whole
  #|  bar*info set.  That's a lot more verbose that the current
  #|  situation, but it is not new, hence the user has less to
  #| learn.
  #|
  #|  But there is still too much room for meaningless specs:
  #| nodist_INFO = bar.info
  #| dist_bar_info_SOURCES = bar.texi
  #| dist_PS = bar.ps something-written-by-hand.ps
  #| nodist_bar_ps_SOURCES = bar.texi
  #| bar_texi_DEPENDENCIES = foo.texi
  #|  here bar.texi is dist_ in line 2, and nodist_ in 4.
  #
  #  Back to the point, it should be clear that in order to support
  #  non-distributed .info files, we need to build them in the
  #  build tree, not in the source tree (non-distributed .texi
  #  files are less of a problem, because we do not output build
  #  rules for them).  In Automake 1.7 .info build rules have been
  #  largely cleaned up so that .info files get always build in the
  #  build tree, even when distributed.  The idea was that
  #(1) if during a VPATH build the .info file was found to be
  #absent or out-of-date (in the source tree or in the
  #build tree), Make would rebuild it in the build tree.
  #If an up-to-date source-tree of the .info file existed,
  #make would not rebuild it in the build tree.
  #(2) having two copies of .info files, one in the source tree
  #and one (newer) in the build tree is not a problem
  #because 'make dist' always pick files in the build tree
  #first.
  #  However it turned out the be a bad idea for several reasons:
  #* Tru64, OpenBSD, and FreeBSD (not NetBSD) Make do not behave
  #  like GNU Make on point (1) above.  These implementations
  #  of Make would always rebuild .info files in the build
  #  tree, even if such files were up to date in the source
  #  tree.  Consequently, it was impossible to perform a VPATH
  #  build of a package containing Texinfo files using these
  #  Make implementations.
  #  (Refer to the Autoconf Manual, section "Limitation of
  #  Make", paragraph "VPATH", item "target lookup", for
  #  an account of the differences between these
  #  implementations.)
  #* The GNU Coding Standards require these files to be built
  #  in the source-tree (whe

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  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

[Tom Tromey]

> "Stefano" == Stefano Lattarini  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

[Roumen Petrov]

Hi Stefano,

Stefano Lattarini wrote:

[SNIP]
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.
Sound like if user would like to distribute binaries they must be in 
source directory .
Why generated file, not required for build process, has to be places in 
source tree.


What if author(s) would like to separate process of document creation 
from binaries ?



  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).
May be I miss what is rationale to keep read-only and build-ready source 
tree.


[SNIP]

Roumen

P.S. I'm not member of all list so I just post to automake list.

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  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  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

[Tom Tromey]

> "Stefano" == Stefano Lattarini  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

[Tom Tromey]

> "Stefano" == Stefano Lattarini  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 05:16 PM, Tom Tromey wrote:
>> "Stefano" == Stefano Lattarini  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

[Stefano Lattarini]

On 04/02/2012 04:25 PM, Tom Tromey wrote:
>> "Stefano" == Stefano Lattarini  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.
>


  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



> 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

[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

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

[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 Ian, Joseph, and sorry for the delay.

On 03/29/2012 01:43 AM, Ian Lance Taylor wrote:
> Stefano Lattarini  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 
>> 
>> and ).
> 
> 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