groff
[Top][All Lists]
Advanced

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

Re: [Groff] releasing new groff version soon


From: Keith Marshall
Subject: Re: [Groff] releasing new groff version soon
Date: Sun, 4 Apr 2004 18:18:27 +0100

On Monday 22 March 2004 3:00 pm, Werner LEMBERG wrote:
> Dear groffers,
>
>
> I think it is time to release a new version of groff, 1.19.1, in a
> month or so.
>
> Please check the current development snapshot (or CVS) for any
> problems.

There are still some issues concerning the setting of 'GROFF_BIN_PATH', and 
prefixing it to 'PATH', in 'nroff.sh' and 'neqn.sh', particularly on the 
various Microsoft platforms.

The problems arise because there is no standard shell implementation in the 
Microsoft world, (apart from cmd.exe and command.com, neither of which can 
run these shell scripts).  Thus, there is a plethora of third party shell, 
(and POSIX environment), emulations, each of which has its own distinct 
convention for handling the differences between the Microsoft PATH notation 
and the POSIX standard.

I think we need to provide a mechanism which will allow these shell scripts 
to select an appropriate notation, (wrt drive identifiers, colons vs. 
semicolons, and slashes vs backslashes), when the script is run.  I did 
consider making the choice at 'configure' or 'make' time, but rejected the 
idea, since Windows users like prebuilt binary packages, (such as the 
GnuWin32 package maintained by Kees Zeelenberg), and the package builder 
cannot preempt the end user's choice of shell emulation.

The attached patch file, shdeps.patch (in patches.tar.bz2), illustrates the 
technique I propose for solving this problem.  It adds a new directory, 
arch/misc, containing two new files, Makefile.sub and shdeps.sh, and modifies 
the top level Makefile.in, and also the nroff.sh and neqn.sh and their 
associated Makefile.sub's, to ensure that appropriate dependencies are built 
in to the two generated scripts, when groff is built.  In formulating this 
solution, I have assumed:--

-  when the configured makefile variables $(RT_SEP) = $(SH_SEP) = ':', then
   the target environment is completely POSIX compliant, and we can generate
   scripts using 100% POSIX syntax;

-  in other cases, we can assume a Microsoft target environment, and the
   generated scripts should incorporate a case statement to identify the
   shell which is in use, and adopt appropriate syntax for setting
   'GROFF_BIN_PATH' and 'PATH'.

This current patch set offers specific solutions for the MSYS shell 
environment, and also for a binary distribution running in the Cygwin 
environment, with a default which appears correct for DJGPP.  It is possible 
that other specific targets may need to be identified, if the supplied 
default is not suitable -- (Jeff, can you check for MKS and SFU, please?)

Just a couple of additional comments:--

-  I have avoided using backslashes in the generated 'GROFF_BIN_PATH', (and
   thus also in 'PATH');  AFAIK, *all* Microsoft environments are equally
   happy to accept the POSIX preferred '/' as a hierarchical delimiter in
   file paths, and trying to get backslashes into the generated scripts
   causes no end of grief -- it just is not worth the effort.

-  the @SEP@ and @BINDIR@ substitutions in the Makefile.sub's for nroff.sh
   and neqn.sh are now redundant;  I have left them in place for now, since
   they are harmless;  however, they should probably eventually be removed,
   for the sake of tidiness.

BTW, when I run nroff from Cygwin, I always see the error message "locale: 
not found"; this is because I do not have the locale command installed, and 
there is a bug in the stderr redirection of Cygwin's sh.exe.  The error 
occurs both with native Cygwin builds of groff, and with Win32 native builds 
run from Cygwin; it is not fatal, but the message is irritating.  Of course, 
I could eliminate it by installing locale, (or a dummy in its place), but a 
fairly minor change in nroff.sh can work around the Cygwin bug -- it is in 
the attached nroff.cygwin.patch (also in patches.tar.bz2).

Werner, both of these patches are working, for every test case I have 
considered.  You may, however, wish to invite comment from others, before 
implementing them.  Please also note that my choice of 'arch/misc' for the 
new files is entirely arbitrary; I will not be offended if you prefer an 
alternative location.

Best regards,
Keith.

Attachment: patches.tar.bz2
Description: BZip2 compressed data


reply via email to

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