Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
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
On 04/03/2012 10:39 PM, Tom Tromey wrote: Stefano == Stefano Lattarini stefano.lattar...@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
On 04/04/2012 01:53 AM, Miles Bader wrote: Pedro Alves pal...@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
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
On 04/04/2012 01:53 AM, Miles Bader wrote: Pedro Alves pal...@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
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
On 04/03/2012 10:39 PM, Tom Tromey wrote: Stefano == Stefano Lattarini stefano.lattar...@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
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 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
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
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: de715b44d25ad523b558d7321ce87bcf8c0cdb09.1333483415.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@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.lattar...@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
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
Stefano == Stefano Lattarini stefano.lattar...@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 stefano.lattar...@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
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
Pedro Alves pal...@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
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: de715b44d25ad523b558d7321ce87bcf8c0cdb09.1333483415.git.stefano.lattar...@gmail.com
From: Stefano Lattarini stefano.lattar...@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.lattar...@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
Re: bug#11034: Binutils, GDB, GCC and Automake's 'cygnus' option
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 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
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 == Stefano Lattarini stefano.lattar...@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 stefano.lattar...@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
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
Pedro Alves pal...@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
On 04/02/2012 04:25 PM, Tom Tromey wrote:
Stefano == Stefano Lattarini stefano.lattar...@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
On 04/02/2012 05:16 PM, Tom Tromey wrote: Stefano == Stefano Lattarini stefano.lattar...@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
Stefano == Stefano Lattarini stefano.lattar...@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 == Stefano Lattarini stefano.lattar...@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
On 04/02/2012 09:36 PM, Tom Tromey wrote: Stefano == Stefano Lattarini stefano.lattar...@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
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 == Stefano Lattarini stefano.lattar...@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
On 04/02/2012 10:19 PM, Tom Tromey wrote:
Stefano == Stefano Lattarini stefano.lattar...@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
Stefano Lattarini stefano.lattar...@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
Hi Stefano, Stefano Lattarini wrote: On 04/02/2012 10:19 PM, Tom Tromey wrote: Stefano == Stefano Lattarinistefano.lattar...@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*. 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
Hi Ian, Joseph, and sorry for the delay. On 03/29/2012 01:43 AM, Ian Lance Taylor wrote: 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 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
- 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
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
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
