bug-groff
[Top][All Lists]
Advanced

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

[bug #62357] [build] tests using "locale charmap" skipped on macOS


From: G. Branden Robinson
Subject: [bug #62357] [build] tests using "locale charmap" skipped on macOS
Date: Thu, 19 May 2022 22:29:20 -0400 (EDT)

Update of bug #62357 (project groff):

                  Status:               Need Info => In Progress            

    _______________________________________________________

Follow-up Comment #11:

[comment #10 comment #10:]
> Strange, I'm not seeing a "./build" directory after building.

Naw, that's not strange, I just momentarily forgot that not everyone does
out-of-tree builds by default like I do.

The "INSTALL.extra" file
<https://git.savannah.gnu.org/cgit/groff.git/tree/INSTALL.extra> documents
both forms of building.  It's currently undergoing revision, but as far as I
remember nothing about the build location has been inaccurate.

> Instead, each of the executables are merely dumped into the checkout's root
directory. Here's the output of `git status --ignored` in case it helps to
elucidate which build directories are misconfigured:
https://pastebin.com/7rtmxDT6

I scanned over this and nothing looks amiss.  We probably want to add the
test-generated .log and .trs files to .gitignore.

> 
> > If even _that_ doesn't work, try this.
> 
> I ran the command with `./build/{troff,font,grotty}` mapped to
`./{troff,font,grotty}` instead (owing to the reasons I described above).
Here's the output:
> 
> 
> $ printf '" \\[rs] ` - '"'"' ^ ~\n' | ./troff -R -F font -F ./font -Tutf8 |
./grotty -F ./font | od -c
> 0000000                                            "       \       ‘  **
> 0000020   **       ‐  **  **       ’  **  **       ˆ  **       ˜  ** 
\n
> 0000040   \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
> *
> 0000140   \n                                                            
> 0000141
> 

Aha.  I think we're onto the scent of the beast now.  The correct glyphs are
appearing, it's just that the UTF-8 continuation bytes are being represented
as double-asterisks instead of spaces!

This is a portability problem.  I'll go see what POSIX says about 'od -c'.  I
can either modify the regex in the test script, or change the output format
with 'od -b' or similar, and just match the octal representations.

> Alternatively, using xxd(1):
> 
> $ printf '" \\[rs] ` - '"'"' ^ ~\n' | ./troff -R -F font -F ./font -Tutf8 |
./grotty -F ./font | xxd -u -g1
> 00000000: 20 20 20 20 20 20 20 20 20 20 22 20 5C 20 E2 80            " \ ..
> 00000010: 98 20 E2 80 90 20 E2 80 99 20 CB 86 20 CB 9C 0A  . ... ... .. ...
> 00000020: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
> 00000030: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
> 00000040: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
> 00000050: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
> 00000060: 0A
> 

This looks kosher to me.  My output:


$ printf '" \\[rs] ` - '"'"' ^ ~\n' | ./build/troff -R -F font -F build/font
-Tutf8 | ./build/grotty -F build/font | xxd -u -g1
00000000: 20 20 20 20 20 20 20 20 20 20 22 20 5C 20 E2 80            " \ ..
00000010: 98 20 E2 80 90 20 E2 80 99 20 CB 86 20 CB 9C 0A  . ... ... .. ...
00000020: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000030: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000040: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000050: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000060: 0A                                               .


The problem is a divergence between Linux 'od -c' output and macOS (BSD?) 'od
-c' output.  Except I haven't heard any complaints from Ingo, so this may be a
true macOS-ism.

Thank you for your help tracking this down.  I think you can disregard this
test failure.

I'm still a little worried that your failure changed to a SKIP at one point,
though.  Those asterisks should be causing a FAIL against the current design
of the test, no question.

We'll see what happens.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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