[bug #62551] [PATCH] doc/groff.texi: Fix content and style nits

[G. Branden Robinson]

Follow-up Comment #6, bug #62551 (project groff):


[comment #5 comment #5:]
> [comment #3 comment #3:]
> > It should these days!  Or, rather, it will if you have the
> > requisite tools installed.
> 
> I think I fell into the cracks of the timeline.  I last built on April 23,
just before commit c21f1a0e
<http://git.savannah.gnu.org/cgit/groff.git/commit/?id=c21f1a0e>.  I can't
tell from the commit log whether this is the commit that pulled the plug on
"make doc" -- it updated NEWS to that effect, but it's characterized at the
top as a refactor, which to me implies no functionality change.

I may have abused the term.  I remember thinking after Ingo's commit that
"make doc" should now do nothing, but I have no clear memory of testing that.

> This commit was a follow-on to Ingo's commit 3805d2a0
<http://git.savannah.gnu.org/cgit/groff.git/commit/?id=3805d2a0>, which _was_
in the tree I built, so _maybe_ I was supposed to get these files with an
unadorned "make"?  Anyway, I won't consider this a bug until I've built with
all the latest changes and see what happens then.

Yes.  If building from Git you definitely _should_ get groff.dvi and
groff.pdf.  This is a consequence of Ingo's commit.

> > What happens when you cd into your build directory (a no-op
> > if you build in the source tree) and say
> > 
> > 
> > make groff.dvi
> > make groff.pdf
> > 
> > 
> > ?
> 
> If I do that literally, I get "No rule to make target 'groff.dvi'.  Stop." 
But if I do what I deduce you meant, "make doc/groff.pdf", I get... a couple
thousand lines of errors and a build failure. \-:  None of this was output
when I built the rest of groff, so (at least as of a month and a half ago) a
simple "make" did not attempt to run this step.

Yes, that's what I meant.  "make doc/groff.{dvi,[df}".  *baghead*

And yes.  Suddenly the groff infrastructure is more aggressive about trying to
build those files.  In fact the only way to stop it without altering the
Makefiles is to fake it out (possibly with dummy target files).

> The errors appear to be related to outdated TeX tools, so also are not
something I think groff need be concerned with.  A huge number of the lines
are repetitions of:
> 
> kpathsea: Running mktextfm lcircle10
> /usr/share/texmf-dist/web2c/mktexnam: Could not map source abbreviation  for
lcircle10.
> /usr/share/texmf-dist/web2c/mktexnam: Need to update ?
> mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; ;
nonstopmode; input lcircle10
> This is METAFONT, Version 2.7182818 (TeX Live 2020 Gentoo Linux) (preloaded
base=mf)
> 
> 
> kpathsea: Running mktexmf lcircle10
> ! I can't find file `lcircle10'.
> <*> ...our; mag:=1; ; nonstopmode; input lcircle10
>                                                   
> Please type another input file name
> ! Emergency stop.
> <*> ...our; mag:=1; ; nonstopmode; input lcircle10
>                                                   
> Transcript written on mfput.log.
> grep: lcircle10.log: No such file or directory
> mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; ; nonstopmode; input
lcircle10' failed to make lcircle10.tfm.
> kpathsea: Appending font creation commands to missfont.log.
> 

Yes, the foregoing is far beyond my ken.  This is why they have the word
"TeXpert".

But I'm guessing you're right--probably a package upgrade or, at worst,
reinstall of your TeX distribution will clear it up.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62551>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/