bug-groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #62274] test-groff.in: wrong order of directories in GROFF_TMAC_PAT


From: G. Branden Robinson
Subject: [bug #62274] test-groff.in: wrong order of directories in GROFF_TMAC_PATH
Date: Sat, 9 Apr 2022 21:20:22 -0400 (EDT)

Update of bug #62274 (project groff):

                  Status:                    None => Invalid                
             Assigned to:                    None => gbranden               
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #1:


[comment #0 original submission:]
> Subject: test-groff.in: wrong order of directories in GROFF_TMAC_PATH
> 
>   The files in the source directory get used (as the first hit) but not
> the corresponding ones in the build directory.

File names in the source and build trees are always different; it is this
discipline that allows _groff_ to use _make_ as a build tool.

If the present ordering a problem for font paths, for instance, it would not
be possible to successfully use the 'utf8' device with test-groff.


$ ls build/font/devutf8
B  BI  DESC  I  R
$ ls font/devutf8
DESC.proto  NOTES  R.in  R.proto  devutf8.am
$ echo "Hello, world!" | ./build/test-groff -Tutf8 | cat -s
Hello, world!



Observe that none of the files in the source directory _font/devutf8_ have
names that the output driver will attempt to open.  And yet, it quietly
manages to do so anyway.  (I do not have $GROFF_FONT_PATH set.)

>   So, as long as the stripped versions were created, they never(?) got
> used (tested) in the repository (which uses "test-groff").

That observation refers to a state of affairs that no longer obtains.  We no
longer strip the macro packages, and there is no prospect of restoring this
function.

In any case, the unstripped versions were present in the source tree with
names ending in "-u", so they would not be loaded except by specially crafted
"-m" arguments of "mso" requests anyway.

Closing as invalid.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]