[Top][All Lists]

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

Re: handling of missing AR

From: Ralf Wildenhues
Subject: Re: handling of missing AR
Date: Thu, 30 Mar 2006 13:18:11 +0200
User-agent: Mutt/1.5.11

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.


reply via email to

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