bug-automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#54063: automake cannot run without generated Texinfo manual


From: Karl Berry
Subject: 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'.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]