[bug #51003] "test-groff" can't find doc-macros in the "tmac/mdoc" directory

[Ingo Schwarze]

Update of bug #51003 (project groff):

Severity: 3 - Normal => 1 - Wish
Item Group: None => Build/Installation


_______________________________________________________

Reply to this item at:

<http://savannah.gnu.org/bugs/?51003>

_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/

[G. Branden Robinson]

Update of bug #51003 (project groff):

Status: None => Need Info
Assigned to: None => gbranden

_______________________________________________________

Follow-up Comment #5:

I think actually Bjarni was right here. Scrubbing those pointless mdoc/
prefixes from the arguments to the .mso calls makes it straightforward to just
run groff (even a system groff) on the built groff_mdoc.7 with the macros from
the build.

This works for out-of-tree builds:


groff -t -M build/tmac -mdoc build/tmac/groff_mdoc.7 2>&1 >/dev/null


And in-tree ones:


groff -t -M tmac -mdoc tmac/groff_mdoc.7 2>&1 >/dev/null


This happens to fix the test-groff case with no extra effort.


./build/test-groff -t -mdoc ./build/tmac/groff_mdoc.7 2>&1 > /dev/null # out
of tree
./test-groff -t -mdoc ./tmac/groff_mdoc.7 2>&1 > /dev/null # in tree


Now, the question that really animates me is why .mso wasn't screaming to
stderr when it couldn't find mdoc/whatever. It's supposed to; I was just
hacking on input.cpp:macro_source() the other day. But that's a separate
bug.

Proposed fix attached. Ingo, please comment if you have a moment.


(file #45421)
_______________________________________________________

Additional Item Attachment:

File name: 51003.diff Size:0 KB


_______________________________________________________

Reply to this item at:

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

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

[Ingo Schwarze]

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

gbranden@, re comment #5 and file #45421:

I think your proposed patch is *very* wrong. If i apply that to my installed
version of doc.tmac, it totally breaks formatting of manual pages with groff:

***@isnote $ groff -mandoc -Tascii -P -c /usr/share/man/man1/cat.1
troff: /usr/local/share/groff/1.22.4/tmac/doc.tmac:58: warning: can't
find macro file 'doc-nroff'
troff: /usr/local/share/groff/1.22.4/tmac/doc.tmac:59: warning: can't find
macro file 'doc-common'
troff: /usr/local/share/groff/1.22.4/tmac/doc.tmac:60: warning: can't find
macro file 'doc-syms'
troff: /usr/share/man/man1/cat.1:62: warning: macro 'doc-get-arg-width' not
defined (possibly missing space after 'do')
Usage: .Ex -std in sections 1, 6 and 8 only (#99)
cat cat Flbenstuv Ar The cat utility reads files sequentially,
writing them to the standard output. The file operands are
[...]

I still don't think there is any problem to solve. Just close this ticket as
invalid.

_______________________________________________________

Reply to this item at:

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

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

[G. Branden Robinson]

Follow-up Comment #7, bug #51003 (project groff):

In groff 1.22.3, a subdirectory of tmac called mdoc is shipped and populated
with the files that are being sourced:


$ dpkg -L groff-base|grep 'tmac.*doc'
/usr/share/groff/1.22.3/tmac/andoc.tmac
/usr/share/groff/1.22.3/tmac/doc-old.tmac
/usr/share/groff/1.22.3/tmac/doc.tmac
/usr/share/groff/1.22.3/tmac/mandoc.tmac
/usr/share/groff/1.22.3/tmac/mdoc
/usr/share/groff/1.22.3/tmac/mdoc/doc-common
/usr/share/groff/1.22.3/tmac/mdoc/doc-ditroff
/usr/share/groff/1.22.3/tmac/mdoc/doc-nroff
/usr/share/groff/1.22.3/tmac/mdoc/doc-syms
/usr/share/groff/1.22.3/tmac/mdoc.tmac


I'll see if we're still doing that. I'll also play around with
GROFF_TMAC_PATH to see if I can get those .mso requests to complain when they
should be.

I'm not giving up on this yet because I really want to be able to A/B changes
to groff_mdoc (or the macro package itself, for that matter) in built trees
without having to do an install.

Without the patch, that's totally unreasonable. If you run the commands in my
earlier comments, you get vast quantities of unholy spew.


$ groff -t -M build/tmac -mdoc build/tmac/groff_mdoc.7 2>&1 >/dev/null | head
Usage: .Sh section_name ... (#115)
Usage: .Sh section_name ... (#245)
Usage: .Ss not callable by other macros (#261)
Usage: .Li argument ... (#313)
Usage: .Li argument ... (#316)
Usage: .Li argument ... (#320)
Usage: .Li argument ... (#322)
build/tmac/groff_mdoc.7:325: warning: macro `doc-first-parameter' not defined
(possibly missing space after `do')
build/tmac/groff_mdoc.7:325: warning: macro `doc-get-width' not defined
(possibly missing space after `do')
build/tmac/groff_mdoc.7:325: warning: macro `doc-get-arg-width' not defined
(possibly missing space after `do')

[literally ONE THOUSAND MORE LINES of stderr snipped]

I may end up agreeing with you, but I'm not willing to admit defeat yet.

_______________________________________________________

Reply to this item at:

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

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

[G. Branden Robinson]

Update of bug #51003 (project groff):

Status: Need Info => In Progress


_______________________________________________________

Reply to this item at:

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

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

[Ingo Schwarze]

Follow-up Comment #8, bug #51003 (project groff):

gbranden@ re comment #7:

Yes, git master HEAD still installs the four doc-* macro files into tmac/mdoc,
that didn't change.

I wouldn't object to installing them directly into the main tmac/ macro
directory as tmac/doc-*.tmac - it's not that polluting, after all, it's only
four files. Of course, that requires changing the four .mso statements in
doc.tmac at the same time.

_______________________________________________________

Reply to this item at:

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

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

[Bjarni Ingi Gislason]

Follow-up Comment #9, bug #51003 (project groff):

My thoughts:

1) The methodology of mdoc-macros is different from the tmac-ones.
They deserve thus a different "mother"-directory (../).
That is used in the installed software.

2) Changes of directory names in installed software can cause problems
if some local files rely on the names being invariant.

3) The problem that "test-groff" poses, is that a different
"mother-directory" name is used for the repository, build-directory
and the installed one.

Conclusion:

Use the same name for the "mother-directory" in all places:
repository, build-directory, tar-file, and the installation.

So the task would be:

1) to create a tmac/mdoc directory in the repository and move the
(non-tmac) "mdoc-*" files" (the four unstripped ones) to that one

2) adjust the *.am files to the changes.


_______________________________________________________

Reply to this item at:

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

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

[G. Branden Robinson]

Update of bug #51003 (project groff):

Open/Closed: Open => Closed
Planned Release: None => 1.22.5

_______________________________________________________

Follow-up Comment #10:

This has been discussed on the development list multiple times over the years,
and no one objected to the idea of fixing it on principle.

There were basically two ways to fix it:

1. Make the installation tree look more like the build tree, with all the
doc-* macro files in the same directory.

2. Make the build tree look more like the installation tree, with the
"modules" of the mdoc package in an mdoc/ subdirectory of tmac/.

I went with option 2. Churn for the dev team is less objectionable than churn
for users, and besides I think it is a good idea to reinforce by example the
notion that a macro package need not be implemented as a flat hierarchy.
Option 1 would not have done this.

Also, now this problem is in my way. See bug #58992.

Fixed in de1e4091311d74ab2af19aa0d376c5d228a14280.

_______________________________________________________

Reply to this item at:

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

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

[G. Branden Robinson]

Update of bug #51003 (project groff):

Status: In Progress => Fixed


_______________________________________________________

Reply to this item at:

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

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