[asterisk-dev] [asterisk-commits] rizzo: trunk r89452 - in?/trunk: acinclude.m4 configure configure.ac

[Steven Critchfield]

On Tue, 2007-11-20 at 10:55 -0800, Luigi Rizzo wrote:
> On Tue, Nov 20, 2007 at 01:28:34PM -0500, Simon Perreault wrote:
> > On Tuesday 20 November 2007 13:20:49 Luigi Rizzo wrote:
> > > it is actually a big burden. there are 145 different version of each of the
> > > tools, some of which are incompatible with each other,
> > > and not all build on all platforms.
> > 
> > This statement sounds awfully like FUD.
> > 
> > What's wrong with autoconf >= 2.60? That's the official guideline, hardcoded 
> > into configure.ac. Pretty much any distribution nowadays comes with it.
> 
> "pretty much" != "every". As a matter of fact one of my main boxes
> has freebsd.4.11 and autoconf is stuck at 2.59 and there are reasons
> why i need to run asterisk there and i cannot upgrade certain pieces
> of software or hardware. BTW building and running software on a
> variety of platforms helps a lot finding bugs and bogus assumptions
> in the code.
> 
> But irrespective of my or your needs, autotools are for portability,
> and it would be a total waste of time to use them and support only
> platform X. As it is a waste of time this discussion.

So the question still stands that shouldn't we support the vast majority
directly while not making it hard for the rest. 

The FreeBSD 4.11 you run was released 1-25-2005, or pretty long ago as
far as OSS software is concerned. Shouldn't we consider this to be an
edge case for direct support? There is nothing stopping you from
creating the configure script elsewhere with a proper autotools version
and merging it in with the code on it's way to your old install?
Essentially we are just moving the responsibility from a dev running the
autotools and commiting the results to the dev getting ready to compile
from svn. 

And in your case of wanting to run it on hardware/OS you can't upgrade,
would it be safe to say that your older install is a production machine
requiring lots of thought before changes are made? If so, would you not
feel more comfortable using releases instead of SVN checkouts on that
machine? I am not of the opinion of necessarily removing the
autogenerated parts from the releases. 
 
-- 
Steven Critchfield <critch at basesys.com>