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/
