[Groff] Re: MSVC Port

[Werner LEMBERG]

[I've CCed my answer to the groff mailing list since some of the
issues might be of general interest.]

> I've successfully built groff 1.19.1.

Congratulations!

> I haven't yet installed 1.19.2, because I had made a number of
> changes to devlj4, and want to make sure my changes will be
> compatible with 1.19.2 before applying them.

What exactly do you mean with 1.19.2?  The latest release is 1.19, and
I assume that 1.19.1 identifies the curren CVS, right?

No changes have been applied to devlj4 since 1.19.  No changes to
lj4.tmac either.

> I've formatted a number of mm- and man- coded documents without any
> major problems.  Large parens and braces formatted for Tlj4 have
> many unsightly gaps (and there even are a few with Tps), but this
> isn't much different from what I get with groff 1.17.2.

Since I don't have a lj4 printer, I actually can't test by myself.
Some time ago I got screen shots how a lj4 renders the groff_char
manual page; the only problem I could find was the lozenge glyph
(\[lz]): For reasons unknown to me grolj4 apparently handles this
glyph having zero-width.

BTW, are there new printers which still use PCL5?  Does grolj4 work
with PCL6 printers?

> I can send you the files diffs if you like (and remind me of the
> format), but I doubt that you'd actually want to modify the files as
> I've done.  Many of the changes to the c and cpp files probably
> could be incorporated into a header file such as nonposix.h.  Given
> my overall understanding of the groff architecture, I'm hardly the
> best one to make that decision.

I'll do that.  If you have the `diff' program please use the `-u'
option to generate the diffs.  Otherwise please send me the whole
changed source files (compressed) privately.

> Configuration Script
> ====================
> Windows uses nul rather than /dev/null; the MKS Kornshell recognizes
> /dev/null for redirects and the test builtin, but '. /dev/null'
> fails.  Running configure with the 'C' option fixes the problem.  I
> don't think the behavior of the MKS Kornshell makes sense (and MKS
> seem to agree), but configure probably could easily avoid the
> problem of how Windows shells deal with OS differences by defining a
> NULLDEV or something similar.

This has been reported to the autoconf team.  Hopefully, a future
version of autoconf fixes that.

> Test for C/C++ Compilers
> ------------------------
> The test for the C and C++ compilers is run before EXEEXT is
> determined, and configure fails to find cl.  Hacking configure to
> test for cl.exe affords a temporary fix, but the test for EXEEXT to
> earlier in the script and using the results would seem the proper
> fix.

No, it isn't.  EXEEXT determines the extension of the binaries
produces by the compiler.  If cross-compiling, this might be
different.

Tim Van Holder <address@hidden> gave the following answer
on the bug-autoconf list (you may check the replies at
http://mail.gnu.org/archive/html/bug-autoconf):

  Another fix is to set ac_executable_extensions to ".exe" (or ".exe
  .cmd .bat" if you like) in your config.site.  That variable was
  added for this exact purpose - not all Unixy shells on DOS/Windows
  return true for 'test -x foo' if only foo.exe exists.

This is an undocumented feature of autoconf:

  That's because it's currently a bit of a hack to get path searches
  working properly for DJGPP (without relying on kludges in bash) and
  OS/2.  It's not really an autoconf feature until it can somehow
  detect the proper list (and using the 'test for feature, not for
  platform' mantra, that's rather difficult in this case).

(so if you have an idea, write him :-) 

My suggestion was to have a small predefined list of extensions (just
".exe", to be precise) to try if the compiler name without extensions
doesn't work.  Let's see how (and when) the autoconf people will fix
that.

> Test for 'g' Option
> -------------------
> The test for the 'g' option to the C and C++ compilers succeeds,
> even though cl doesn't accept the 'g' option.  MSVC succeeds in
> compiling the file, but gives the following output:
>
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
> Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
>
> Command line warning D4002 : ignoring unknown option '-g'
>
> I don't claim to fully understand the test, but it seems that
> evaluating
>
>     ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err'
>
> should be the place to catch it.  The second test is never
> performed, however, because ac_c_werror_flag is not set.

Forwarded to bug-autoconf.

> I actually invoked configure as
>
> configure -C --prefix='C:/usr/local' \
>           CFLAGS='-O2 -G6 -nologo' CXXFLAGS='-O2 -G6 -nologo'
>
> I could have added CC=cl and CXX=cl eliminate the search for the
> compilers.

Just curious: If you say `CC=cl.exe' and `CXX=cl.exe' does it then
work without a configure script patch related to EXEEXT?

> [... many small subtleties omitted ...]
>
> pipeline.c
> ----------
> MSVC wants (but does not require) _itoa() rather than itoa(), and
> requires 3 parameters rather than 1.  I find this a bit amazing,
> because I had no problem building this file with the Unix-style
> itoa() when I submitted the changes for groff 1.17.2

This has been already fixed in the current CVS by using i_to_a.

Thanks for your efforts!


    Werner