Re: handling of missing AR
On Thu, 30 Mar 2006, Ralf Wildenhues wrote:
> * Tim Mooney wrote on Thu, Mar 30, 2006 at 12:19:13AM CEST:
> [...]
> > The real question is, does libtool's configure macro know whether ar is
> > needed. You seem to be indicating that it never knows (in any case)
> > whether ar is needed. Am I understanding that correctly?
>
> I am trying to say that I can imagine good uses of AC_PROG_LIBTOOL even
> without --disable-shared that do not involve `ar'.
>
> Here may be an idea to come closer to what you'd like: maybe by default
> we should fail on missing AR, LD(?), RANLIB(?), NM(??) (increasingly
> questionable), and add options to LT_INIT([OPTIONS..]) (which is how CVS
> Libtool spells AC_PROG_LIBTOOL) that would allow to override this
> failure. Hmm. Need to think about this. That would at least be better
> than, say, an interface such as AC_PROG_LIBTOOL([RUN-IF-AR-FAILS],
> [RUN-IF-NM-FAILS], ...) with all failure arguments defaulting to `:'.
>
> Other than that, I'm still not totally against the idea that "configure
> does not have to fail, even if it may find out that the build will
> fail". Hard failures are easy to detect and fix; obviously that becomes
> less convenient as packages grow in size and build time. But I for one
> dislike it when I need four attempts until the configure step completes:
> all those 3 warnings could maybe have been given in one run already, and
> at least then the cache file would have been populated for further
> runs.. (and yes, I know that (parts of) the cache file may be invalid
> for following runs with different settings)
Disclaimer: I'm no expert whatsover in libtool. So I make no claims to
understand the details of this issue.
What you describe seems analogous to an issue that we tackled on the
"autoconf" side of the "linux-ha" (www.linux-ha.org) project. We recently
tidied up some of the optional things, originally "--enable-XYZ={yes|no}",
that its "autoconf" stage does, because that binary yes/no choice was
inadequate for our range of end-users.
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}
with "try" having a meaning along the lines of:
"if possible 'yes'; else soft fail to 'no' and proceed"
and setting many of our defaults to that "try" value, and processing them
with those "soft fail" semantics. (If they explicitly say "yes" and
configure detects an inconsistency, this is a "hard fail" and it bails
out.)
This has had the huge benefit of giving new end-users a "configure" that
actually completes. They can then quickly move on to a final product
(albeit one that may lack some desirable (but not vital) aspects), or they
can (if they choose) address some of the warnings that those "try"
defaults generated.
Might that model, that frame of mind, help in this "libtool" cases of
things like "AR", and the various not-necessarily-be-used compilers?
--
: David LeeI.T. Service :
: Senior Systems ProgrammerComputer Centre :
: Durham University :
: http://www.dur.ac.uk/t.d.lee/South Road:
: Durham DH1 3LE:
: Phone: +44 191 334 2752 U.K. :
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: handling of missing AR
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
Re: handling of missing AR
Ralf Wildenhues writes: > Erm. The user did not have /usr/ccs/bin in $PATH? Right, /usr/ccs/bin was not in the PATH. > Well yes, but sometimes ar is not needed, for example it /may/ not be > needed when --disable-static is given. Okay > Naa. Kean Johnston already suggested adding /usr/ccs/bin to the PATH > for those tests (or was that /usr/ccs/bin/elf or both? I'll go and > check). Could you check with the user that those tools are available > there? Then let's do that to fix the actual failure instead. I've checked and they do have ar in /usr/ccs/bin so that would work. -- Brian Gough ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: handling of missing AR
On 2006-03-29, Brian Gough <[EMAIL PROTECTED]> wrote: > checking for ar... false > [...] > false cru .libs/libutils.a .libs/placeholder.o > make[2]: *** [libutils.la] Error 1 If AR defaulted to "$(MISSING) ar" if no ar was found (instead of false), then no error is given if ar is not found but never used, but the end user gets a more helpful error if it's not found and is used: WARNING: `ar' is needed, and is missing on your system. You might have modified some files without having the proper tools for further handling them. Check the `README' file, it often tells you about the needed prerequisites for installing this package. You may also peek at any GNU archive site, in case some other package would contain this missing `ar' program. The message could be better (the second sentence is wrong), but it's better than that quoted above. It could easily be improved too - just add a case for ar to the missing script with a more specific error. Cheers, Olly ___ http://lists.gnu.org/mailman/listinfo/libtool
