Re: handling of missing AR

[Ralf Wildenhues]

Hi David,

* David Lee wrote on Thu, Mar 30, 2006 at 11:36:59AM CEST:
> 
> For some of our options, when end-user feature "XYZ" is nice but is not
> actually essential, we now have a local (developer) convention of:
>    --enable-XYZ={yes|no|try}

[ nice explanation of default and soft failure ]

Generally, this is a very good idea IMVHO.  In fact, we've been using a
similar approach in some of our projects.  ;-)

(BTW, you can use `--enable-XYZ=@<:@yes|no|try@:>@', the alignment will
look ok once Autoconf-2.60 is out and you use it.)

> Might that model, that frame of mind, help in this "libtool" cases of
> things like "AR", and the various not-necessarily-be-used compilers?

Hmm.  That would be something like: if the user explicitly sets AR but
it does not work, configure should fail?  This is really the rare
situation: usually we search for the first `ar' we find in the $PATH,
I have seen very few uses where AR was actually set manually.  But yes,
I assume that would be sensible to do, even if it doesn't help with the
specific situation at hand.

Please note that we actually have a TODO item to test whether $AR does
the functionality of $RANLIB itself so that, as an optimization, $RANLIB
may be skipped then (most of the time), or alternatively, whether $AR
understands the `S' modifier so we don't build the symbol table more
often than necessary.  Those tests will be similarly runtime-expensive
as testing whether $AR/$RANLIB work at all.

Cheers,
Ralf