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

[Keith Marshall]

On Wednesday 19 May 2004 3:17 pm, Jon Snader wrote:
> On Wed, May 19, 2004 at 02:26:16PM +0100, Jim Reid wrote:
> > Once upon a time, I tried to put groff on an HP-UX box that had no C++
> > compiler. So I had to fight the HP C compiler to get gcc installed so
> > that I could install g++. [Yes, it was that long ago that gcc and g++
> > were separate.] Oh and I had to install bison and flex to be able to
> > compile gcc. g++ needed the GNU assembler and linker. So they had
> > to be installed too. But the GNU linker didn't grok the HP-UX .o and
> > .a formats. Game over after a few weeks of work. Needless to say none
> > of these dependencies/requirements were documented at the outset. I
> > hope we're not heading back to those days. And all of that effort was
> > so I could typeset some documents....
>
> Heh!  Yup, I remember trying to build gcc on some strange
> platform.  I had an experience just like the one you're
> describing.  But as you say, that was long ago and far away.
> These days the Gnu toolset is available for pretty much any
> Unix/Linux like system--or even  Windows--as precompiled binaries.
>
> I find that as a practical matter almost every program I want to
> build was developed using the Gnu toolset, and that life is much
> easier if I simply have them available.  That's why I always
> add gmake, bash, and friends to my BSD systems--it just makes life
> easier.
>
> > The Linux-isms that appear to be pervading groff are not primarily
> > about gnu make. It's things like hardwiring /bin/bash into the
> > autoconfiguration. First of all, no absolute pathname should ever be
> > hard-wired into configure. And in the case of groff, this pathname
> > ends up in the Makefile, even if /bin/bash doesn't exist! To make
> > matters worse, it seems to be there so that make can run shdeps.sh
> > which is a *Bourne* shell script. So there appears to have been no
> > need for bash in the first place even if its correct pathname was
> > used. This kind of thing is very disturbing. And it seems to pervade
> > the Linux world.
>
> It's hard to disagree with this, of course.  Things like hard
> coded paths in shell scripts are usually a matter of a developer
> being rushed or lazy or just plain forgetting to do the right
> thing.  I know I've been guilty of it at times, and I certainly
> know better.
>
> My main point is that if we are going to build free/open
> multiplatform software from scratch, we should probably expect to
> have to do a little work.  My Linux distribution, for example,
> likes to put everything in /usr/bin, even those things which
> every other distribution puts in /usr/local/bin.  That means I
> have to tweak the config script or Makefile.  That's annoying,
> but then I remember that I'm getting all this wonderful software
> at no real cost from *volunteers* (mostly) who have other jobs
> and duties to take care of too.  It seems like a small price.  In
> the mean time, others are tightening the bolts by fixing
> dependencies, so that we won't have to pay even that small price.
> I applaud those folks, but I also don't complain about the
> developers who assume I'm using Gnu tools (well, except perhaps
> for a small private mutter when I have to adjust install paths
> and such).

Thanks for this vote of confidence, Jon.

Jim Reid's continuing rant is becoming quite irritating now, especially 
since his principal contention is actually refuted by evidence present in his 
own original posting.  He complains of a hard coded requirement for 
/bin/bash, in the groff Makefile, yet the failing command in his is make 
error report clearly shows that the shell in use was /usr/contrib/bin/bash.

The actual cause of this failure had nothing whatsoever to do with the choice 
of bash as the make shell, nor anything to do with the shdeps.sh script that 
it was supposed to execute -- it was due to the use of $<, to refer to 
shdeps.sh, in an explicit make rule.  Apparently, this is ok with GNU make, 
but is unsafe with other variants, such as his BSD make.  This was quickly 
identified, and Werner has already applied an appropriate patch to the CVS, 
so this should now not fail, even with non-GNU implementations of make.

Jim's remaining problem also has absolutely nothing to do with the choice of 
shell -- rather, it would seem that, having compiled and built all the groff 
binaries, the DESC file for the postscript output device cannot be located by 
the troff binary.  I don't know why this should be, but it certainly isn't 
related to any GNU preference for bash as the shell, so why does he keep 
banging on about it?

BTW, I cannot fathom where this notion that bash is required as the build 
shell, and that it must live in /bin, has come from -- I see nothing in the 
groff aclocal.m4 which stipulates this.  Perhaps autoconf has a preference to 
select it, provided it can find it in the PATH, or in /etc/shells, when the 
generated configure script is invoked -- I don't know, and life is too short 
for me to devote time to trying to figure out how configure handles this -- I 
will happily leave that concern to the autoconf developers.

On my GNU/Linux box, bash gets selected as the build shell, but then I use it 
by my own choice anyway.  On my Win2K box, I use the MSYS port of the GNU 
tool chain, with the MinGW port of gcc -- this has /bin/sh as the shell, bash 
is not present in the PATH, and there is no /etc/shells, so configure selects 
/bin/sh as the build shell.  Groff 1.19.1 makes, installs, and executes OOTB 
on *both* machines -- how can this be on the Win2K box, if /bin/bash *must* 
be present, when it most definitely is not?

Perhaps Jim should concentrate on identifying, and solving, the real problem 
which is apparent on his box, instead of making an issue of something 
imagined, rather than real, and for which he has shown no real evidence.  
Alternatively, since nobody is twisting his arm to choose groff, perhaps he 
should put his hand in his wallet, and invest in a binary implementation of 
AT&T troff, for his BSD box.

Best regards,
Keith.