Re: [patch] Keep sanity in autotools

[Eric Sunshine]

On Wed, 10 Dec 2003 10:03:35 -0800, Bruce Korb wrote:
> This is plain nutty.

Indeed.  Portability issues almost always are.  At any rate, I was not  
suggesting that that approach be used, but rather was pointing out potential  
problems in the proposal, along with some possible solutions.  I am all in  
favor of simpler and cleaner solutions, and it seems that we have finally  
arrived at one.

> What is terribly wrong with requiring a minimalist install environment
> pre-installed?  You know, autoconf checks for it and if it has not been
> installed and echo and grep don't work, then just choke and die.

But how does one define a "minimalist" environment, and if one person's idea  
of minimal makes numerous assumptions which are not exactly minimal, then  
how would truly minimal environments be configured in the first place?  There  
has to be some way to bootstrap the environment, and to do so means  
utilizing the tools which are already available on that platform, such as  
Bourne shell, make, etc.  It is precisely tools, such as Autoconf, m4, gcc,  
and whatnot, which cater to the bootstrapping process, thus it makes sense to  
put extra effort into these tools to ensure that they are able to fulfill  
that role.  It is not necessary to spend an enormous amount of time pandering  
to portability for every single project, but it is useful to do so for the  
few tools which make bootstrapping possible.

> How many programmer hours are squandered hassling over silly
> things that were fixed 20 years ago?

Many of the issues that Autoconf handles are not 20 years old; plenty are  
much more recent than that.  At any rate, the goal of Autoconf is to insulate  
developers from these portability issues as much as possible.  It is  
precisely this insulation which frees the majority of programmers from having  
to waste their time over portability concerns.  If one person can spend a  
few hours enhancing Autoconf, then everyone else benefits without having to  
waste any of their own time.  Thus, "programmer hours" have been gained, not  
wasted.

> At what point are hobbiest platforms dropped so
> that programmers can presume target platforms that are less than a decade
> old?  Sheesh!  What a waste of time.

It is not just a matter of hobbyist platforms.  There are plenty of  
businesses using technology more than a decade old, which can not simply  
ditch their legacy platforms in favor of newer technology.  In a large  
corporate environment it can take a long, long time to migrate to newer  
technology, so being able to build and utilize modern tools on these older  
platforms is can be very important.  Programmers and users can benefit  
greatly from modern tools even if they are constrained to working on legacy  
platforms, and would likely not consider the effort put into Autoconf to be a  
waste of time.  One of my jobs was working as part of a small team to  
replace antiquated mainframe software (for a hospital system), which itself  
was 15 or 20 years old.  We chose modern hardware and modern technology  
(NextStep 2.1 - 3.3) and produced a very high-tech system which is still in  
use today.  But, guess what?  At 12 or 14 years old, that system is also now  
a legacy system probably quite in need of replacement, yet it is still up and  
running all these years later.  Corporate migration tends to go very slowly.  
 It is not just a matter of dropping in new hardware and popping in some new  
software, but instead often involves creation of entire new systems and  
infrastructures, so tools such as Autoconf, and projects which care about  
portability and legacy systems, are important and welcome.

-- ES