bug#54063: automake cannot run without generated Texinfo manual
Karl Berry , 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
bug#54063: automake cannot run without generated Texinfo manual
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!
bug#54063: automake cannot run without generated Texinfo manual
I meant to include the patch I actually applied.
commit 5c85a9d31830a61facc298fa7d7d82f5651f1a6c
Author: Bogdan
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,
bug#54063: automake cannot run without generated Texinfo manual
Karl Berry , 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
bug#54063: automake cannot run without generated Texinfo manual
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.
bug#54063: automake cannot run without generated Texinfo manual
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'.
bug#54063: automake cannot run without generated Texinfo manual
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
bug#54063: automake cannot run without generated Texinfo manual
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 Description: PGP signature
bug#54063: automake cannot run without generated Texinfo manual
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
bug#54063: automake cannot run without generated Texinfo manual
Runtime warning in texi2any or automake? Both?
bug#54063: automake cannot run without generated Texinfo manual
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
bug#54063: automake cannot run without generated Texinfo manual
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 ...
bug#54063: automake cannot run without generated Texinfo manual
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
bug#54063: automake cannot run without generated Texinfo manual
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
Description: PGP signature
bug#54063: automake cannot run without generated Texinfo manual
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
bug#54063: automake cannot run without generated Texinfo manual
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
Description: PGP signature
bug#54063: automake cannot run without generated Texinfo manual
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
