groff
[Top][All Lists]
Advanced

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

[Groff] Re: groff build/release engineering


From: Jon Snader
Subject: [Groff] Re: groff build/release engineering
Date: Wed, 19 May 2004 10:17:54 -0400
User-agent: Mutt/1.4.2.1i

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).

jcs


reply via email to

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