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
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
