#2236 "make info" fails for sources from master
running "make info" in the docs subdirectory of git master results in:
Updated level "5" menu following node: x11 ...
Updated level "3" menu following node: Bugs ...
Making or updating menus in doc2texi...done
Done...updated all the menus. You may save the buffer.
/bin/sh /home/haawda/paketierung/meine_Pakete/gnuplot-git/src/gnuplot/missing makeinfo -I. gnuplot.texi --no-split --output=gnuplot.info
gnuplot.texi:11735: warning: @ref should not appear in @uref
gnuplot.texi:23535: warning: unknown @end itemizeif
gnuplot.texi:23540: warning: unknown @end itemizeif
gnuplot.texi:23579: warning: unknown @end itemizeif
gnuplot.texi:23953: warning: unknown @end itemizeif
gnuplot.texi:24656: warning: unknown @end itemizeif
gnuplot.texi:25410: warning: unknown @end itemizeif
gnuplot.texi:25418: warning: unknown @end itemizeif
gnuplot.texi:25442: warning: unknown @end itemizeif
gnuplot.texi:25450: warning: unknown @end itemizeif
gnuplot.texi:26004: warning: unknown @end itemizeif
gnuplot.texi:26034: warning: unknown @end itemizeif
gnuplot.texi:26200: warning: unknown @end itemizeif
gnuplot.texi:26238: warning: unknown @end itemizeif
gnuplot.texi:26624: warning: unknown @end itemizeif
gnuplot.texi:26629: warning: unknown @end itemizeif
gnuplot.texi:4915: @ref reference to nonexistent node origin'
gnuplot.texi:7397: @ref reference to nonexistent nodeorigin'
gnuplot.texi:9003: @ref reference to nonexistent node origin'
gnuplot.texi:9017: @ref reference to nonexistent nodeorigin'
gnuplot.texi:9039: @ref reference to nonexistent node origin'
gnuplot.texi:12718: @ref reference to nonexistent nodeorigin'
gnuplot.texi:15378: @ref reference to nonexistent node origin'
gnuplot.texi:15789: @ref reference to nonexistent nodeorigin'
gnuplot.texi:15791: @ref reference to nonexistent node origin'
gnuplot.texi:15808: @ref reference to nonexistent nodeorigin'
gnuplot.texi:15817: @ref reference to nonexistent node origin'
gnuplot.texi:15832: @ref reference to nonexistent nodeorigin'
gnuplot.texi:16448: @ref reference to nonexistent node origin'
gnuplot.texi:17075: @ref reference to nonexistent nodeorigin'
make: *** [Makefile:1223: gnuplot.info] Error 1
==> ERROR: A failure occurred in build().
Gnuplot no longer supports info. Possibly it would help to install the emacs gnuplot-mode
https://github.com/bruceravel/gnuplot-mode but I have never tried that so I cannot say for sure.
Nevertheless if you have the resources to investigate the problem and want to submit a patch for the relevant code (doc2texi I suppose, although maybe it's the emacs+elisp script) I'd be happy to apply it.
Last edit: Ethan Merritt 2020-03-10
This bug causes a normal 'make && make install' to fail. That is, the project
fails to build with this bug.
Please find attached a patch that fixes this regression.
Pardon my doubt, but you are the only person to report build failure so it must not be true that "make && make install" fails for everyone. Certainly it has never failed for me. Since "info" is not a default make target, why is it failing?
So that I can understand why your patch fixes something, can you explain to me why adding an '=' character after the subsection title of a LaTeX document makes a difference other than to create incorrect entries in the LaTeX output?
Is it that "origin" is a reserved word at some step of the processing?
If so I would much rather deal with a fix at that step rather than incorrectly documenting the "origin" keyword in pdf and other output formats.
Would it accomplish the same thing to add a non-printing charater instead? For instance adding a <tab> rather than a '=' would make the change invisible in LaTeX output.</tab>
On Sun, 22 Mar 2020, Ethan Merritt wrote:
You are correct; I had forgotten that my packager also calls: make install-info
It seems that having a command and keyword using the same name breaks texi
x-refs; I assume that the processor has no way to detect which one is to be
used for the reference. The breakage seems to be from commands causing the
creation of a texi 'node' that can be referenced, and keywords are not given a
texi 'node' and therefore break references.
I agree it would be nice to make the processor better at handling it. However,
I do not know emacs lisp (or any lisp as far as that goes). I can imagine
getting it to understand which 'origin' all of the x-ref are supposed to point
at would be difficult. It looks like the source gnuplot.doc only encloses the
x-refs in back-ticks without any indication of the target they point to. I
suspect other existing name collisions are causing false pointers. If I recall
correctly 'palette' has three; a command, a function, and a keyword? I think
all of the x-refs are pointing to the function.
I don't know; it originally had a trailing space that seemed to get the job
done. I based the patch on the history of the gnuplot project. I listed
the commits as references in the patch. Here they are with some additional
explanation:
2910176: first committed by you with a trailing 'space'
ce3d86b: then you removed the trailing space and broke the build
33315b5: the build was fixed by adding a trailing '='
a522faa: then the current regression happened by removing the '='
So a trailing character has been required, and in use, since you introduced
it on Nov 26 2004.
I made the (perhaps incorrect) assumption that when the last fix was committed
everyone in-the-know approved of the trailing '='. I suppose the biggest
problem with depending on any trailing character is that in the future someone
will assume it's a typo and remove it again.
Related
Bugs:
#2236Some light dawns. So it had magic trailing whitespace that made something work. Then several of us started cleaning up trailing whitespace as encountered, partly prompted by the change to git, which highlights trailing whitespace in red whenever you do a diff or review a pending commit. I can put a tab or blank space back in, but that seems really fragile.
Then you touch on something that may be the heart of the problem:
In a bit of brilliance or a stroke of madness, the gnuplot.doc text conventions were designed to be interpreted orthogonally by different output filters. The doc->tex filter looks for lines beginning with
#, the doc->gih filter looks for lines beginning with "?", and so on. Lines beginning with a digit are intended to be interpreted by doc->tex to create section/substection/paragraph level formatting. They are ignored by other filters.So far so good, but what about the indexing? TeX index entries are generated either by a line beginning with a digit (because it creates a section heading) or a line beginning with a '='. gih/help index entries are generated by lines beginning with '?'. These conventions are supposed to be orthogonal. From your description it seems that the doc->texi filter is either using the TeX convention incorrectly (the digit acts as a differentiator), or is using a mixture of the '?' and 'digit" conventions and creating a conflict. I see code in doc2tex.el that claims to be using the '?' lines for indexing. I think it should not be doing that at all.
I conclude that the fix belongs in doc2texi.el but I have lost track of who, if anyone, might be maintaining that. I had thought that it was taken over by the gnuplot-mode package (https://github.com/bruceravel/gnuplot-mode) but now I don't see it there. Looks like the most recent substantive changes to the copy we have were submitted by Shige Takeno (2017) and Ulrich Müller (2013).
By the way, I still don't understand what would be special about "origin". The same issue of having entries at multiple sectioning levels applies also to "bins" "boxplot" "examples" "every" and so on.
On Sun, 22 Mar 2020, Ethan Merritt wrote:
I 'think' it is somewhat by chance. When name collisions happen it starts
appending underscores ''. So: origin, origin, ... Whichever one matches the
x-ref is blessed as the reference. If it happens to be a keyword, it will not
get a 'node', which is like the anchor for texi x-refs; thereby breaking the
x-ref and causing makeinfo to bail.
Thank you for the explanation of the gnuplot.doc format. It doesn't look like
there is a way to add a comment to it. If there is, a comment warning to not
remove the trailing character might solve the problem.
Related
Bugs:
#2236The problem is fixed in master. Creating the info file works again.
I also confirm that commit 93edc94 allows 'make install-info' to succeed.