groff
[Top][All Lists]
Advanced

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

Re: [Groff] Re: groff build/release engineering


From: MARSHALL Keith
Subject: Re: [Groff] Re: groff build/release engineering
Date: Thu, 20 May 2004 10:57:11 +0100

Jim,

> configure has somehow decided to hard-wire /bin/bash into the Makefile
> despite the facts that (a) there is no /bin/bash; (b) /usr/contrib/bin
> is in the search path and bash lives there; ...

I can't explain why this should be, perhaps there is a bug in autoconf;
if so, you want to be reporting it to the autoconf developers, *not* the
groff developers!  All I can say for sure is that I don't see this on *my*
system (Win2K) -- bash is present in a Cygwin install tree, but when I
use the MSYS tool chain, with the MinGW port of gcc, the only shell
visible on the PATH is /bin/sh, and configure correctly sets SHELL=/bin/sh
in the generated Makefile.

> ... (c) $SHELL appears only to
> get used by make to invoke your Bourne shell script shdeps.sh even
> though it could just run shdeps.sh directly. Creating this sort of
> unnecessary dependency -- even if the pathname was right! -- is bad
> release engineering.

This is *not* an unnecessary dependency -- it is *essential* for the
MS-Windows build environment, where there is no attribute to mark a
file as executable.  My /bin/sh is in reality /bin/sh.exe -- the
executable nature of the file is indicated by the .exe extension.
MS-Windows doesn't know that .sh files should be executable, and the
standard MS cmd.exe shell couldn't parse the Bourne shell syntax in
any case.  MSYS' sh.exe identifies files as executable, either by
a MS standard executable extension to the file name, which .sh isn't,
or by the presence of a shebang at the head of a script.  Ok, shdeps.sh
has #!/bin/sh, but what if /bin/sh doesn't exist?  So, which is better
engineering;  to impose a shebang dependency for a shell which may not
exist, or to force the execution by a shell which *should* be present,
if configure did its job correctly?  Please do not condemn design
decisions, when you don't understand the reasons for taking them.

> ... Nobody's given any pointers to help
> me troubleshoot what DESC file groff is unable to find.

I did tell you *explicitly* which DESC file troff was unable to find.
You have not confirmed, at least on the groff mailing list, that it
has been created, and is properly accessible.  My own contribution to
groff development is small, compared to that of many others.  I have
done my best to offer you advice, on the basis of the information you
have posted -- that no-one else has replied is most likely because
they have nothing more to add, given the limited information you
provided.  Someone out there may well be able to help you better than
I, but they need more, relevant, information, to help identify the
cause of your problem.

Regards,
Keith.


reply via email to

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