GNU bug report logs - #54063
automake cannot run without generated Texinfo manual

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 54063 in the body.
You can then email your comments to 54063 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Patrice Dumas <pertusus <at> free.fr>
To: bug-automake <at> gnu.org
Cc: Gavin Smith <gavinsmith0123 <at> gmail.com>
Subject: automake cannot run without generated Texinfo manual
Date: Sat, 19 Feb 2022 15:03:38 +0100

Hello,

Please CC me, I am not subscribed.

In Texinfo, we have a texinfo manual which is automatically generated
from Pod sections from Texinfo perl modules.  When this generated manual
is removed, automake cannot run anymore.  To workaround this issue, we
have a generation of a fake manual that contains only @setfilename manual.info 
in the autogen.sh script that can be used to bootstrap some other
autogenerated things, in particular Makefile fragments.  However, this
is not practical, in particular if the generated manual is removed and
the Makefile.am file is modified, one need to redo a fake manual in
order to have things being ok again.

It seems to me that one way to avoid the issue would be if automake used
only the texinfo manual name to construct the rules.  It would probably
be a good thing to do irrespective of this issue, as @setfilename is not
as important as it used to be, now it is fully optional, and we probably
should consider as a best practice not to have @setfilename in Texinfo
manuals.

The manual is in doc/tp_api in the texinfo sources, it is tp_api.texi.


I have not checked, but I think that a minimal reproducer would be
a Makefile.am with:

###########################################
info_TEXINFOS = my_manual.texi

BUILT_SOURCES = my_manual.texi

my_manual.texi: pre_my_manual.texi
	cat $< > $@

##########################################



With pre_my_manual.texi having only one line

@setfilename my_manual.info

-- 
Pat

Message #8 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Patrice Dumas <pertusus <at> free.fr>
Cc: 54063 <at> debbugs.gnu.org, Gavin Smith <gavinsmith0123 <at> gmail.com>
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Thu, 24 Feb 2022 01:52:21 -0500

[Message part 1 (text/plain, inline)]

On 19 Feb 2022 15:03, Patrice Dumas wrote:
> In Texinfo, we have a texinfo manual which is automatically generated
> from Pod sections from Texinfo perl modules.  When this generated manual
> is removed, automake cannot run anymore.  To workaround this issue, we
> have a generation of a fake manual that contains only @setfilename manual.info 
> in the autogen.sh script that can be used to bootstrap some other
> autogenerated things, in particular Makefile fragments.  However, this
> is not practical, in particular if the generated manual is removed and
> the Makefile.am file is modified, one need to redo a fake manual in
> order to have things being ok again.
> 
> It seems to me that one way to avoid the issue would be if automake used
> only the texinfo manual name to construct the rules.  It would probably
> be a good thing to do irrespective of this issue, as @setfilename is not
> as important as it used to be, now it is fully optional, and we probably
> should consider as a best practice not to have @setfilename in Texinfo
> manuals.
> 
> The manual is in doc/tp_api in the texinfo sources, it is tp_api.texi.

automake already has some fallback logic if @setfilename isn't set -- it
uses the basename of the source file and changes .texi to .info.  but it
doesn't work if the file doesn't exist.  i think that should be easy to
support.

--- a/bin/automake.in
+++ b/bin/automake.in
@@ -3062,7 +3062,8 @@ sub scan_texinfo_file
 {
   my ($filename) = @_;
 
-  my $texi = new Automake::XFile "< $filename";
+  my $source = -e $filename ? $filename : "/dev/null";
+  my $texi = new Automake::XFile "< $source";
   verb "reading $filename";
 
   my ($outfile, $vfile);

if this is the only thing you need, then i won't think any harder about it.
-mike

[signature.asc (application/pgp-signature, inline)]

Message #11 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Patrice Dumas <pertusus <at> free.fr>
To: 54063 <at> debbugs.gnu.org, Gavin Smith <gavinsmith0123 <at> gmail.com>
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Thu, 24 Feb 2022 11:19:04 +0100

On Thu, Feb 24, 2022 at 01:52:21AM -0500, Mike Frysinger wrote:
> On 19 Feb 2022 15:03, Patrice Dumas wrote:
> > In Texinfo, we have a texinfo manual which is automatically generated
> > from Pod sections from Texinfo perl modules.  When this generated manual
> > is removed, automake cannot run anymore.  To workaround this issue, we
> > have a generation of a fake manual that contains only @setfilename manual.info 
> > in the autogen.sh script that can be used to bootstrap some other
> > autogenerated things, in particular Makefile fragments.  However, this
> > is not practical, in particular if the generated manual is removed and
> > the Makefile.am file is modified, one need to redo a fake manual in
> > order to have things being ok again.
> > 
> > It seems to me that one way to avoid the issue would be if automake used
> > only the texinfo manual name to construct the rules.  It would probably
> > be a good thing to do irrespective of this issue, as @setfilename is not
> > as important as it used to be, now it is fully optional, and we probably
> > should consider as a best practice not to have @setfilename in Texinfo
> > manuals.
> > 
> > The manual is in doc/tp_api in the texinfo sources, it is tp_api.texi.
> 
> automake already has some fallback logic if @setfilename isn't set -- it
> uses the basename of the source file and changes .texi to .info.  but it
> doesn't work if the file doesn't exist.  i think that should be easy to
> support.
> 
> --- a/bin/automake.in
> +++ b/bin/automake.in
> @@ -3062,7 +3062,8 @@ sub scan_texinfo_file
>  {
>    my ($filename) = @_;
>  
> -  my $texi = new Automake::XFile "< $filename";
> +  my $source = -e $filename ? $filename : "/dev/null";
> +  my $texi = new Automake::XFile "< $source";
>    verb "reading $filename";
>  
>    my ($outfile, $vfile);
> 
> if this is the only thing you need, then i won't think any harder about it.

I have not tested but it looks good (or a variation with the same effect
if /dev/null is not portable).  The only issue I see is if after the
file is generated the @setfilename is not the same as the file base name
there will be errors.  I do not think that automake should support that
setup, but maybe it would be good to state it in the documentation.
Maybe something like:

"Texinfo files that are generated should have a basename matching
@setfilename, if there is a @setfilename."

Thanks!

-- 
Pat

Message #14 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Patrice Dumas <pertusus <at> free.fr>
Cc: 54063 <at> debbugs.gnu.org, Gavin Smith <gavinsmith0123 <at> gmail.com>
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Thu, 24 Feb 2022 22:32:20 -0500

[Message part 1 (text/plain, inline)]

On 24 Feb 2022 11:19, Patrice Dumas wrote:
> On Thu, Feb 24, 2022 at 01:52:21AM -0500, Mike Frysinger wrote:
> > On 19 Feb 2022 15:03, Patrice Dumas wrote:
> > > In Texinfo, we have a texinfo manual which is automatically generated
> > > from Pod sections from Texinfo perl modules.  When this generated manual
> > > is removed, automake cannot run anymore.  To workaround this issue, we
> > > have a generation of a fake manual that contains only @setfilename manual.info 
> > > in the autogen.sh script that can be used to bootstrap some other
> > > autogenerated things, in particular Makefile fragments.  However, this
> > > is not practical, in particular if the generated manual is removed and
> > > the Makefile.am file is modified, one need to redo a fake manual in
> > > order to have things being ok again.
> > > 
> > > It seems to me that one way to avoid the issue would be if automake used
> > > only the texinfo manual name to construct the rules.  It would probably
> > > be a good thing to do irrespective of this issue, as @setfilename is not
> > > as important as it used to be, now it is fully optional, and we probably
> > > should consider as a best practice not to have @setfilename in Texinfo
> > > manuals.
> > > 
> > > The manual is in doc/tp_api in the texinfo sources, it is tp_api.texi.
> > 
> > automake already has some fallback logic if @setfilename isn't set -- it
> > uses the basename of the source file and changes .texi to .info.  but it
> > doesn't work if the file doesn't exist.  i think that should be easy to
> > support.
> > 
> > --- a/bin/automake.in
> > +++ b/bin/automake.in
> > @@ -3062,7 +3062,8 @@ sub scan_texinfo_file
> >  {
> >    my ($filename) = @_;
> >  
> > -  my $texi = new Automake::XFile "< $filename";
> > +  my $source = -e $filename ? $filename : "/dev/null";
> > +  my $texi = new Automake::XFile "< $source";
> >    verb "reading $filename";
> >  
> >    my ($outfile, $vfile);
> > 
> > if this is the only thing you need, then i won't think any harder about it.
> 
> I have not tested but it looks good (or a variation with the same effect
> if /dev/null is not portable).

automake already relies on redirecting to /dev/null, so shouldn't be an issue.

> The only issue I see is if after the
> file is generated the @setfilename is not the same as the file base name
> there will be errors.  I do not think that automake should support that
> setup, but maybe it would be good to state it in the documentation.
> Maybe something like:
> 
> "Texinfo files that are generated should have a basename matching
> @setfilename, if there is a @setfilename."

sounds reasonable, but i don't think this is a new issue.
-mike

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: 54063 <at> debbugs.gnu.org
Subject: [PATCH] automake: fall back gracefully when texinfo inputs don't exist
Date: Thu, 24 Feb 2022 22:32:24 -0500

Fixes automake bug https://bugs.gnu.org/54063.

The function scanning for @setfilename will fall back to a default
value if the input doesn't have one defined.  But we need to handle
the case where the file doesn't even exist before falling back.

* bin/automake.in: Scan /dev/null for @setfilename if input doesn't exist.
* t/list-of-tests.mk: Add txinfo-no-setfilename-no-inputs.sh.
* t/txinfo-no-setfilename-no-inputs.sh: New test.
---
 bin/automake.in                      |  4 +++-
 t/list-of-tests.mk                   |  1 +
 t/txinfo-no-setfilename-no-inputs.sh | 31 ++++++++++++++++++++++++++++
 3 files changed, 35 insertions(+), 1 deletion(-)
 create mode 100644 t/txinfo-no-setfilename-no-inputs.sh

diff --git a/bin/automake.in b/bin/automake.in
index 5eba649d240c..13ad4329caeb 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -3062,7 +3062,9 @@ sub scan_texinfo_file
 {
   my ($filename) = @_;
 
-  my $texi = new Automake::XFile "< $filename";
+  # If the source file doesn't exist, we'll fall back below.
+  my $source = -e $filename ? $filename : "/dev/null";
+  my $texi = new Automake::XFile "< $source";
   verb "reading $filename";
 
   my ($outfile, $vfile);
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index d959b68db47b..ec08891555e7 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -1229,6 +1229,7 @@ t/txinfo-no-extra-dist.sh \
 t/txinfo-no-installinfo.sh \
 t/txinfo-no-repeated-targets.sh \
 t/txinfo-no-setfilename.sh \
+t/txinfo-no-setfilename-no-inputs.sh \
 t/txinfo-other-suffixes.sh \
 t/txinfo-override-infodeps.sh \
 t/txinfo-override-texinfo-tex.sh \
diff --git a/t/txinfo-no-setfilename-no-inputs.sh b/t/txinfo-no-setfilename-no-inputs.sh
new file mode 100644
index 000000000000..4cedb2f88d81
--- /dev/null
+++ b/t/txinfo-no-setfilename-no-inputs.sh
@@ -0,0 +1,31 @@
+#! /bin/sh
+# Copyright (C) 2022 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 <https://www.gnu.org/licenses/>.
+
+# Check Texinfo files work without a @setfilename line and no input files.
+# https://bugs.gnu.org/54063
+
+. test-init.sh
+
+cat > Makefile.am << 'END'
+info_TEXINFOS = file.texi
+END
+
+$ACLOCAL
+$AUTOMAKE --add-missing
+
+grep 'file.info:' Makefile.in
+
+:
-- 
2.34.1

Message #20 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Patrice Dumas <pertusus <at> free.fr>
To: 54063 <at> debbugs.gnu.org, Gavin Smith <gavinsmith0123 <at> gmail.com>
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Fri, 25 Feb 2022 16:48:56 +0100

On Thu, Feb 24, 2022 at 10:32:20PM -0500, Mike Frysinger wrote:
> > The only issue I see is if after the
> > file is generated the @setfilename is not the same as the file base name
> > there will be errors.  I do not think that automake should support that
> > setup, but maybe it would be good to state it in the documentation.
> > Maybe something like:
> > 
> > "Texinfo files that are generated should have a basename matching
> > @setfilename, if there is a @setfilename."
> 
> sounds reasonable, but i don't think this is a new issue.

It is not new, sure, but before this change Texinfo generated file were
most probably uncommon, and could be much more common and therefore
there could be more risk for that kind of mismatch now.  Non generated
files can have a basename not matching with the @setfilename without
that being a problem, I think (though I did not test...).

-- 
Pat

Message #23 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: pertusus <at> free.fr
Cc: 54063 <at> debbugs.gnu.org, gavinsmith0123 <at> gmail.com
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Fri, 25 Feb 2022 16:06:34 -0700

Adding a note to the manual is fine, but what would be (much) more
likely to actually get noticed by users is a runtime warning. What is
the actual behavior when the basename and @setfilename don't match?
Sorry to be clueless ...

Message #26 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: pertusus <at> free.fr
To: Karl Berry <karl <at> freefriends.org>
Cc: 54063 <at> debbugs.gnu.org, gavinsmith0123 <at> gmail.com
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Sat, 26 Feb 2022 00:23:48 +0100

On Fri, Feb 25, 2022 at 04:06:34PM -0700, Karl Berry wrote:
> Adding a note to the manual is fine, but what would be (much) more
> likely to actually get noticed by users is a runtime warning. What is
> the actual behavior when the basename and @setfilename don't match?
> Sorry to be clueless ...

Runtime warning in texi2any or automake?

I experienced this issue with automake one time, not on purpose.  I
don't quite remember well, but my recalling is that the output file was
always rebuilt as automake had determined the output file name and the
rules when run previously using the basename, while the files where
created using the @setfilename by makeinfo.

-- 
Pat

Message #29 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: pertusus <at> free.fr
Cc: 54063 <at> debbugs.gnu.org, gavinsmith0123 <at> gmail.com
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Fri, 25 Feb 2022 16:29:11 -0700

    Runtime warning in texi2any or automake?

Both?

Message #32 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: pertusus <at> free.fr
To: Karl Berry <karl <at> freefriends.org>
Cc: 54063 <at> debbugs.gnu.org, gavinsmith0123 <at> gmail.com
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Sat, 26 Feb 2022 00:47:30 +0100

On Fri, Feb 25, 2022 at 04:29:11PM -0700, Karl Berry wrote:
>     Runtime warning in texi2any or automake?
> 
> Both?

It seemed to me that @setfilename in texi2any was actually a way to
have an output file name different from the input file name.  If this is
not really useful, we should simply ignore @setfilename in texi2any
rather than have a runtime warning.

We actually use @setfilename in the test suite to be able to set a file
name for a Texinfo string read from a source file and not from an actual
file.  But there are other ways to specify the file name.

-- 
Pat

Message #35 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Mike Frysinger <vapier <at> gentoo.org>
To: Karl Berry <karl <at> freefriends.org>
Cc: pertusus <at> free.fr, gavinsmith0123 <at> gmail.com, 54063 <at> debbugs.gnu.org
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Sat, 26 Feb 2022 00:07:09 -0500

[Message part 1 (text/plain, inline)]

On 25 Feb 2022 16:06, Karl Berry wrote:
> Adding a note to the manual is fine, but what would be (much) more
> likely to actually get noticed by users is a runtime warning. What is
> the actual behavior when the basename and @setfilename don't match?

i don't think it's possible to detect from automake, at least at `automake`
time.  the point of Patrice's report is that the sources don't exist when
automake runs, so it's not possible to inspect them.  trying to go further
(having automake attempt to trace partial makefile?  have it generate a
check that runs on the user's system at `make` time?) feels like it's
intruding on the territory of texinfo for no real gain.
-mike

[signature.asc (application/pgp-signature, inline)]

Message #38 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: pertusus <at> free.fr
To: Karl Berry <karl <at> freefriends.org>, 54063 <at> debbugs.gnu.org,
 gavinsmith0123 <at> gmail.com
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Sat, 26 Feb 2022 13:08:15 +0100

On Sat, Feb 26, 2022 at 12:07:09AM -0500, Mike Frysinger wrote:
> On 25 Feb 2022 16:06, Karl Berry wrote:
> > Adding a note to the manual is fine, but what would be (much) more
> > likely to actually get noticed by users is a runtime warning. What is
> > the actual behavior when the basename and @setfilename don't match?
> 
> i don't think it's possible to detect from automake, at least at `automake`
> time.  the point of Patrice's report is that the sources don't exist when
> automake runs, so it's not possible to inspect them.  trying to go further
> (having automake attempt to trace partial makefile?  have it generate a
> check that runs on the user's system at `make` time?) feels like it's
> intruding on the territory of texinfo for no real gain.

I agree, especially if a @setfilename different from the file name
is used on purpose to have a different output name than the base name.

I just tested a mismatch between filename and @setfilename with automake.
The file name is toto.texi and @setfilename my_output.info.  make info
works.  make html fails with:

make: *** No rule to make target 'toto.html', needed by 'html-am'.  Stop.

make my_output.html works.

I do not think that this needs to be fixed in case at Texinfo we
consider that @setfilename different from the file name is bad and that
@setfilename more generally should be deprecated.  My recommendation
would be to leave unsaid for now whether automake supports or not a
different file name than @setfilename for non generated texinfo manuals
in case it is later considered relevant, probably based on the advice
from the Texinfo crowd.

-- 
Pat

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: automake-patches <at> gnu.org
Subject: [bug#54063 - special case] Try .texi.in when .texi missing
Date: Tue, 27 Dec 2022 22:48:25 +0100

[Message part 1 (text/plain, inline)]

Hello, Automake gurus.

I have a special case for bug#54063. In my case, the .texi file is 
missing during 'automake' time, because it is being created by 
'configure' from a matching .texi.in file. That file exists during 
'automake' time, so it can be scanned for the output filename - no 
need to use /dev/null in such simple case.

The attached patch (with a test) should fix this issue. Hope I've done 
everything the right way.

-- 
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

[automake-txinfo-no-texi-but-texi-in-mail.diff (text/x-patch, attachment)]

Message #44 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: bogdro_rep <at> gmx.us
Cc: 54063 <at> debbugs.gnu.org, gavinsmith0123 <at> gmail.com, pertusus <at> free.fr
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Thu, 13 Jul 2023 16:34:39 -0600

Bogdan, Pat, Gavin, all - back on this bug:

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063
    Subject: bug#54063: - special case] Try .texi.in when .texi missing

Bogdan - the basic idea of your patch seemed fine, to use .texi.in when
.texi is missing.

After investigating the behavior of @setfilename and Automake, as far as
I can tell, it simply does not work. (Pat, I don't understand how it
worked for you.) As far as I could see, Automake reads the @setfilename,
and changes the .info rule accordingly, but the .texi.info suffix rule
does not run.(*) Automake also does not change the HTMLS variable for
@setfilename, as Pat previously noted.

Therefore, I did not think we should test the case of @setfilename being
different from the basename in .texi.in, since that's not a case that's
supported in Automake. I tweaked your new test
txinfo-no-texi-but-texi-in.  I also added a second item to the new test,
to check the results when the .texi.in has no @setfilename.

Then I wondered what the point was of reading .texi.in at all, if the
@setfilename had to match the basename.  But I guess the answer is, it
could find an @include version.texi.

Also, the original patch needed a small tweak so as to use the original
filename, instead of "/dev/null" -> "null", in the rules when no input
texi[.in] is found.  Otherwise the test txinfo-no-setfilename-no-inputs
failed.

The presence of a .texi[.in] file at all, or an @setfilename directive
within the texi file if it is there, remains optional.

As previously discussed in this bug, I added a warning to automake.texi
about @setfilename having to match the basename if it's present. I think
a check+warning for that could usefully be added to the code in this
function (scan_texinfo_file), but I just can't cope with spending more
time on this issue. I also don't want to think about adding "full"
support for @setfilename to Automake, given that @setfilename is no
longer required or especially recommended for Texinfo.

Wow, this is all confusing. I sure hope it works out (closing the bug,
probably prematurely). --thanks, karl.

(*) I constructed a tiny source tree (in a new/empty directory):

echo '@setfilename bar.texi' >foo.texi
echo 'info_TEXINFOS = foo.texi' >Makefile.am
cat >>configure.ac
AC_INIT([am-texi-fname], [1.0])
AM_INIT_AUTOMAKE
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
^D
aclocal
automake --foreign --add-missing
autoconf
configure
make             # nothing happens
make info        # nothing happens
make ./bar.info  # nothing happens

\grep bar.info Makefile
INFO_DEPS = $(srcdir)/bar.info
$(srcdir)/bar.info: foo.texi 

Nothing is made. I believe because Automake sees the @setfilename and
makes all the rules based on finding a bar.texi, which doesn't exist,
therefore make can't find anything to do. make -d reports:
Rejecting rule '%.info: %.texi' due to impossible prerequisite 'bar.texi'.

Message #52 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Gavin Smith <gavinsmith0123 <at> gmail.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: 54063 <at> debbugs.gnu.org, bogdro_rep <at> gmx.us, pertusus <at> free.fr
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Fri, 14 Jul 2023 12:08:43 +0100

On Thu, Jul 13, 2023 at 04:34:39PM -0600, Karl Berry wrote:
> Bogdan, Pat, Gavin, all - back on this bug:
> 
>     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063
>     Subject: bug#54063: - special case] Try .texi.in when .texi missing
> 


> As previously discussed in this bug, I added a warning to automake.texi
> about @setfilename having to match the basename if it's present. I think
> a check+warning for that could usefully be added to the code in this
> function (scan_texinfo_file), but I just can't cope with spending more
> time on this issue. I also don't want to think about adding "full"
> support for @setfilename to Automake, given that @setfilename is no
> longer required or especially recommended for Texinfo.
> 
> Wow, this is all confusing. I sure hope it works out (closing the bug,
> probably prematurely). --thanks, karl.

I didn't follow the details of the discussion closely, but it appears
to relate to a theoretical problem that didn't actually affect anybody,
only relevant if @setfilename was used.  I agree that it appears to
be an issue not worth spending much time on, and that adding full support
for @setfilename to Automake would be a waste of time and effort.

Looking at the thread of the original bug report above, the original
problem appears to have been fixed by Mike Frysinger's change:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063#17
  Date: Thu, 24 Feb 2022 22:32:24 -0500
  > Fixes automake bug https://bugs.gnu.org/54063.
  > 
  > The function scanning for @setfilename will fall back to a default
  > value if the input doesn't have one defined.  But we need to handle
  > the case where the file doesn't even exist before falling back.

Thus, closing the bug makes sense.

We can see if we can remove the workaround for the original problem
in Texinfo if/when a new version of Automake is released.

Message #55 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: Karl Berry <karl <at> freefriends.org>
Cc: 54063 <at> debbugs.gnu.org, gavinsmith0123 <at> gmail.com, pertusus <at> free.fr
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Fri, 14 Jul 2023 21:03:51 +0200

Karl Berry <karl <at> freefriends.org>, Fri Jul 14 2023 00:34:39 GMT+0200
(Central European Summer Time)
> Bogdan, Pat, Gavin, all - back on this bug:
>
>      https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063
>      Subject: bug#54063: - special case] Try .texi.in when .texi missing
>
> Bogdan - the basic idea of your patch seemed fine, to use .texi.in when
> .texi is missing.
>
> After investigating the behavior of @setfilename and Automake, as far as
> I can tell, it simply does not work. (Pat, I don't understand how it
> worked for you.) As far as I could see, Automake reads the @setfilename,
> and changes the .info rule accordingly, but the .texi.info suffix rule
> does not run.(*) Automake also does not change the HTMLS variable for
> @setfilename, as Pat previously noted.


 *That* deep I didn't look.


> Therefore, I did not think we should test the case of @setfilename being
> different from the basename in .texi.in, since that's not a case that's
> supported in Automake. I tweaked your new test
> txinfo-no-texi-but-texi-in.  I also added a second item to the new test,
> to check the results when the .texi.in has no @setfilename.
>
> Then I wondered what the point was of reading .texi.in at all, if the
> @setfilename had to match the basename.  But I guess the answer is, it
> could find an @include version.texi.


[...]
 As I wrote, my reason and my part of the issue was that I could
distribute just the .texi.in file and still get
autoreconf/automake/packaging to work. Right now, I get an error about
a missing .texi file, so for the time being, I package a stub .texi
file and generate the "real" .texi file with ./configure.
 My point wasn't about reading the .texi.in file if .texi doesn't
exist, just to get the output filename. My point was not to throw
errors if no file with an output filename could be found and use
.texi.in instead (if it exists). Simpler than skipping the check
altogether and assume that the developer will provide all the input
files at the time when they're needed (./configure, autogen.sh-like,
whatever).


> The presence of a .texi[.in] file at all, or an @setfilename directive
> within the texi file if it is there, remains optional.
>
> As previously discussed in this bug, I added a warning to automake.texi
> about @setfilename having to match the basename if it's present. I think
> a check+warning for that could usefully be added to the code in this
> function (scan_texinfo_file), but I just can't cope with spending more
> time on this issue. I also don't want to think about adding "full"
> support for @setfilename to Automake, given that @setfilename is no
> longer required or especially recommended for Texinfo.


 Fine by me. It's you who decides. I just wanted to (re-)add my point
of view and the source of my idea/problem.


> Wow, this is all confusing.


 Indeed. And more complicated than I thought (as usual).


> I sure hope it works out (closing the bug,
> probably prematurely). --thanks, karl.


 Thanks. Hope I helped at least to push this forward.

 Just one more thing:

> (*) I constructed a tiny source tree (in a new/empty directory):
>
> echo '@setfilename bar.texi' >foo.texi


 Shouldn't the above read "bar.info" instead of "bar.texi"?


> echo 'info_TEXINFOS = foo.texi' >Makefile.am
> cat >>configure.ac
> AC_INIT([am-texi-fname], [1.0])
> AM_INIT_AUTOMAKE
> AC_CONFIG_FILES([Makefile])
> AC_OUTPUT
> ^D
> aclocal
> automake --foreign --add-missing
> autoconf
> configure
> make             # nothing happens
> make info        # nothing happens
> make ./bar.info  # nothing happens
>
> \grep bar.info Makefile
> INFO_DEPS = $(srcdir)/bar.info
> $(srcdir)/bar.info: foo.texi
>
> Nothing is made. I believe because Automake sees the @setfilename and
> makes all the rules based on finding a bar.texi, which doesn't exist,
> therefore make can't find anything to do. make -d reports:
> Rejecting rule '%.info: %.texi' due to impossible prerequisite 'bar.texi'.


 Interesting. And more complex than I thought.

--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

Message #58 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: bogdro_rep <at> gmx.us
Cc: 54063 <at> debbugs.gnu.org, gavinsmith0123 <at> gmail.com, pertusus <at> free.fr
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Fri, 14 Jul 2023 15:27:02 -0600

I meant to include the patch I actually applied.

commit 5c85a9d31830a61facc298fa7d7d82f5651f1a6c
Author: Bogdan <bogdro_rep <at> gmx.us>
AuthorDate: Thu Jul 13 15:32:34 2023 -0700

    texi: assume .texi.in generates .texi.
    
    This change refines the fix for https://bugs.gnu.org/54063.
    
    * bin/automake.in (scan_texinfo_file): if .texi doesn't exist,
    but .texi.in exists, read the latter for the Texinfo source.
    Use the @setfilename argument, if present, to generate rules.
    * t/txinfo-no-texi-but-texi-in.sh: new test.
    * t/list-of-tests.mk (handwritten_tests): add it.
    
    * doc/automake.texi (Texinfo): document this.
    * NEWS: mention this.  (Doc changes written by Karl.)
---
 NEWS                            |  6 ++++
 bin/automake.in                 | 37 ++++++++++++++++++++----
 doc/automake.texi               | 32 +++++++++++++++++----
 t/list-of-tests.mk              |  1 +
 t/txinfo-no-texi-but-texi-in.sh | 63 +++++++++++++++++++++++++++++++++++++++++
 5 files changed, 128 insertions(+), 11 deletions(-)

diff --git a/NEWS b/NEWS
index 23b2cc50a..c64d4ef15 100644
--- a/NEWS
+++ b/NEWS
@@ -21,6 +21,12 @@ New in 1.17:
   - Variables using escaped \# will trigger portability warnings, but be
     retained when appended.  GNU Make & BSD Makes are known to support it.
 
+  - For Texinfo documents, if a .texi.in file exists, but no .texi, the
+    .texi.in will be read. Texinfo source files need not be present at
+    all, and if present, need not contain @setfilename. Then the file name
+    as given in the Makefile.am will be used.  If @setfilename is present,
+    it should be the basename of the Texinfo file, extended with .info.
+
 * Bugs fixed
 
   - Generated file timestamp checks now handle filesystems with sub-second
diff --git a/bin/automake.in b/bin/automake.in
index 1c13a3187..369a47fa2 100644
--- a/bin/automake.in
+++ b/bin/automake.in
@@ -3061,11 +3061,24 @@ sub handle_scripts ()
 sub scan_texinfo_file
 {
   my ($filename) = @_;
+  my $orig_filename = $filename;
 
   # If the source file doesn't exist, we'll fall back below.
-  my $source = -e $filename ? $filename : "/dev/null";
-  my $texi = new Automake::XFile "< $source";
-  verb "reading $filename";
+  if (! -e $filename)
+    {
+      if (-e ($filename . '.in'))
+        {
+          # $filename.texi.in exists: assume $filename.texi is generated
+          # and parse $filename.texi.in as the real input.
+          $filename .= '.in';
+        }
+      else
+        {
+          $filename = '/dev/null';
+        }
+    }
+  my $texi = new Automake::XFile "< $filename";
+  verb "reading texinfo_file $filename";
 
   my ($outfile, $vfile);
   while ($_ = $texi->getline)
@@ -3077,6 +3090,18 @@ sub scan_texinfo_file
 	  # to use @setfilename...)
 	  next if $outfile;
 
+	  # Although we notice the @setfilename, and the rules are
+	  # adjusted to sort of use it, they don't actually work.
+	  # Specifically, if foo.texi contains @setfilename bar.info,
+	  # the generated .texi.info suffix rule will not run.
+	  #
+	  # Also, although we change the .info target to be bar.info,
+	  # the HTML(S) variable/etc. is not changed.
+	  #
+	  # Since @setfilename is optional nowadays, doesn't seem worth
+	  # the trouble to handle (which looks to be nontrivial).
+	  # https://bugs.gnu.org/54063
+	  
 	  $outfile = $1;
 	  if (index ($outfile, '.') < 0)
 	    {
@@ -3100,8 +3125,10 @@ sub scan_texinfo_file
 
   if (! $outfile)
     {
-      # Replace a .texi extension with .info
-      $outfile = basename($filename);
+      # If no explicit @setfilename, use the original filename as passed
+      # (not foo.texi.in or /dev/null) in the generated rules, while
+      # replacing any extension (presumably .texi) with .info.
+      $outfile = basename ($orig_filename);
       $outfile =~ s/\.[^.]+$//;
       $outfile .= '.info';
     }
diff --git a/doc/automake.texi b/doc/automake.texi
index 1bf74cd73..4561d1948 100644
--- a/doc/automake.texi
+++ b/doc/automake.texi
@@ -8036,6 +8036,7 @@ Currently Automake provides support for Texinfo and man pages.
 @node Texinfo
 @section Texinfo
 
+@cindex Texinfo support
 @cindex @code{_TEXINFOS} primary, defined
 @cindex @code{TEXINFOS} primary, defined
 @cindex Primary variable, @code{TEXINFOS}
@@ -8069,7 +8070,25 @@ rather than in the @code{builddir}.  This can be changed with the
 If the Texinfo sources are in a subdirectory relative to the Makefile, then
 @code{-I} flags for the subdirectory, both in the source directory and in the
 build directory, will automatically be added.  There is no need to specify
-these in @samp{$(MAKEINFO)}, @samp{$(MAKEINFOFLAGS)}, etc...
+these in @samp{$(MAKEINFO)}, @samp{$(MAKEINFOFLAGS)}, etc.
+
+@cindex @samp{@@setfilename} Texinfo directive
+If a Texinfo source file contains an @samp{@@setfilename} directive,
+and its argument has extension @samp{.info} (or no extension, but this
+is discouraged), that argument should be the same as the basename of
+the Texinfo file, extended with @samp{.info}.  The Make rules
+generated by Automake assume this, and will not work if the
+@samp{@@setfilename} is for some other name.
+
+@cindex @file{.texi.in} file, read
+If a Texinfo source @samp{foo.texi} is not present, but
+@file{foo.texi.in} exists, Texinfo will read that @file{.texi.in} file
+for @code{@@setfilename} and @code{@@include version.texi} (described
+below).
+
+Texinfo source files need not be present at all, and if present, need
+not contain @code{@@setfilename}.  Then the file name given in the
+Makefile.am will be used.
 
 @trindex dvi
 @trindex html
@@ -8102,11 +8121,12 @@ All of these targets can be extended using @samp{-local} rules
 
 @cindex @file{mdate-sh}
 
-If the @file{.texi} file @code{@@include}s @file{version.texi}, then
-that file will be automatically generated.  The file @file{version.texi}
-defines four Texinfo flags you can reference using
-@code{@@value@{EDITION@}}, @code{@@value@{VERSION@}},
-@code{@@value@{UPDATED@}}, and @code{@@value@{UPDATED-MONTH@}}.
+If a @file{.texi} file @code{@@include}s @file{version.texi} (actually
+any file named @file{vers...texi}, then that file will be
+automatically generated.  The file @file{version.texi} defines four
+Texinfo flags you can reference using @code{@@value@{EDITION@}},
+@code{@@value@{VERSION@}}, @code{@@value@{UPDATED@}}, and
+@code{@@value@{UPDATED-MONTH@}}.
 
 @table @code
 @item EDITION
diff --git a/t/list-of-tests.mk b/t/list-of-tests.mk
index 6f25f0494..94781d9b0 100644
--- a/t/list-of-tests.mk
+++ b/t/list-of-tests.mk
@@ -1232,6 +1232,7 @@ t/txinfo-no-installinfo.sh \
 t/txinfo-no-repeated-targets.sh \
 t/txinfo-no-setfilename.sh \
 t/txinfo-no-setfilename-no-inputs.sh \
+t/txinfo-no-texi-but-texi-in.sh \
 t/txinfo-other-suffixes.sh \
 t/txinfo-override-infodeps.sh \
 t/txinfo-override-texinfo-tex.sh \
diff --git a/t/txinfo-no-texi-but-texi-in.sh b/t/txinfo-no-texi-but-texi-in.sh
new file mode 100644
index 000000000..7975d4b01
--- /dev/null
+++ b/t/txinfo-no-texi-but-texi-in.sh
@@ -0,0 +1,63 @@
+#! /bin/sh
+# Copyright (C) 2023 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 <https://www.gnu.org/licenses/>.
+
+# Check if Automake doesn't exit with an error for Texinfo output files
+# without a direct input file, but with a matching input file processed
+# by 'configure' (file.texi.in). 
+# https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063#41
+# 
+# This also tests an @setfilename that is different from the file name,
+# and the lack of any @setfilename, in the case of using .texi.in.
+# (See scan_texinfo_file in automake.)
+
+. test-init.sh
+
+echo AC_OUTPUT >> configure.ac
+
+cat > Makefile.am << 'END'
+info_TEXINFOS = main.texi
+END
+
+cat > main.texi.in << 'END'
+\input texinfo
+@setfilename main.info
+@settitle main
+@node Top
+Hello world.
+@bye
+END
+
+$ACLOCAL
+$AUTOMAKE --add-missing
+
+grep '/main.info:' Makefile.in
+
+# Recreate the test document without @setfilename.
+cat > main.texi.in << 'END'
+\input texinfo
+@settitle main
+@node Top
+Hello world.
+@bye
+END
+
+$ACLOCAL
+$AUTOMAKE
+
+# The result should use main.info (from the .texi file name).
+grep '/main.info:' Makefile.in
+
+:

Message #61 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: bogdro_rep <at> gmx.us
Cc: 54063 <at> debbugs.gnu.org
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Fri, 14 Jul 2023 15:32:21 -0600

    I could distribute just the .texi.in file and still get
    autoreconf/automake/packaging to work. Right now, I get an error
    about a missing .texi file

I thought Mike's fix (-e ... /dev/null) should already have fixed that?

Well, in any case, it's not bad to check for the .texi.in, so I'm happy
you posted about it.

    > echo '@setfilename bar.texi' >foo.texi
    Shouldn't the above read "bar.info" instead of "bar.texi"?

Oops, certainly so! Sharp eyes. Fortunately in my actual test file I got
it right, so I think my description of the (non-)behavior I saw still
stands ... --thanks again, karl.

P.S. Still working on several more patches from you. Thanks for all!

Message #64 received at 54063 <at> debbugs.gnu.org (full text, mbox):

From: Bogdan <bogdro_rep <at> gmx.us>
To: Karl Berry <karl <at> freefriends.org>
Cc: 54063 <at> debbugs.gnu.org
Subject: Re: bug#54063: automake cannot run without generated Texinfo manual
Date: Sat, 15 Jul 2023 18:36:12 +0200

Karl Berry <karl <at> freefriends.org>, Fri Jul 14 2023 23:32:21 GMT+0200
(Central European Summer Time)
>      I could distribute just the .texi.in file and still get
>      autoreconf/automake/packaging to work. Right now, I get an error
>      about a missing .texi file
>
> I thought Mike's fix (-e ... /dev/null) should already have fixed that?


 Well, to be honest, I simply made the fix for the code that was
present in the repo, assuming it would behave the same as the official
version. Indeed, it seems that it works even without my fix. Oh well,
at least one more chance to get the output filename (if present).


> Well, in any case, it's not bad to check for the .texi.in, so I'm happy
> you posted about it.
>
>      > echo '@setfilename bar.texi' >foo.texi
>      Shouldn't the above read "bar.info" instead of "bar.texi"?
>
> Oops, certainly so! Sharp eyes. Fortunately in my actual test file I got
> it right, so I think my description of the (non-)behavior I saw still
> stands ... --thanks again, karl.


 OK, better typo in a mail than in the repo/docs.


> P.S. Still working on several more patches from you. Thanks for all!


 Nice to hear :). It's good that you check them so thoroughly, not
just the code but also asking "is this the way it should work?".


--
Regards - Bogdan ('bogdro') D.                 (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):    http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft  http://bogdro.evai.pl/soft4asm
www.Xiph.org  www.TorProject.org  www.LibreOffice.org  www.GnuPG.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.