[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #51003] "test-groff" can't find doc-macros in the "tmac/mdoc" direc
From: |
Ingo Schwarze |
Subject: |
[bug #51003] "test-groff" can't find doc-macros in the "tmac/mdoc" directory |
Date: |
Thu, 11 May 2017 16:13:40 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; OpenBSD amd64; rv:53.0) Gecko/20100101 Firefox/53.0 |
Follow-up Comment #1, bug #51003 (project groff):
I suspect this ticket to be invalid.
> Man-pages include "doc"-macros with a request ".mso mdoc/...".
No. They don't. In the complete OpenBSD ports tree (nearly 10k ports), i'm
not aware of a single port doing that.
If any manual page would do that, it would be extremely bad style, not serving
any purpose whatsoever but introducing pointless fragility. No manual page
should ever contain any .mso request.
The way to format a manual page is calling "nroff -mandoc" (or troff -mandoc).
If you are sure it is mdoc(7) and not man(7), you can also say "nroff -mdoc",
but there is no real reason why the user should bother. The page itself
certainly must not attempt to second-guess the system roff installation.
> The directory "mdoc" does not exist in the git-repository.
True. But for one thing, source directory layout need not match the layout of
the installed software. Here, a directory like ".../groff/1.22.3/tmac/mdoc/"
does get created at install time, see tmac/tmac.am, variable $(mdocdir) for
details.
Then, it doesn't matter. All that is called externally - and not by the end
user or the manpage itself, but by man(1)! - is the main macro file,
../groff/1.22.3/tmac/doc.tmac, which is *not* inside the mdoc/ subdir. That
file includes whatever it needs.
> A fix could be
A fix for what exactly? Which problem are you trying to solve?
> to create the directory and links in that directory
Certainly not. There is no need whatsoever to have duplicate versions of
files in the source tree. That would only cause confusion.
> A comment in "doc.tmac":
Admittedly, that comment is ridiculous nowadays. If worrying about systems
unable to handle filenames longer than 8+3 bytes ever made sense (which i
doubt), those times are over for at least two decades. But i don't see much
benefit in renaming stuff, the current names work and people got used to them.
Maybe the comment could be changed to say "nonstandard naming for historical
reasons", but that doesn't seem very pressing either.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?51003>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/