Subject: Re: bug#54063: automake cannot run without generated Texinfo manual

From: Bogdan <[email-masked]>
Date: Fri, 14 Jul 2023 21:03:51 +0200

Karl Berry <[email-masked]>, 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