emacs-bug-tracker
[Top][All Lists]
Advanced

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

bug#54063: closed (automake cannot run without generated Texinfo manual)


From: GNU bug Tracking System
Subject: bug#54063: closed (automake cannot run without generated Texinfo manual)
Date: Thu, 13 Jul 2023 22:35:02 +0000

Your message dated Thu, 13 Jul 2023 16:34:39 -0600
with message-id <202307132234.36DMYdJw016947@freefriends.org>
and subject line Re: bug#54063: automake cannot run without generated Texinfo 
manual
has caused the debbugs.gnu.org bug report #54063,
regarding automake cannot run without generated Texinfo manual
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
54063: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54063
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- 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



--- End Message ---
--- Begin Message --- 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'.


--- End Message ---

reply via email to

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