[Top][All Lists]

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

Re: handling of missing AR

From: David Lee
Subject: Re: handling of missing AR
Date: Thu, 30 Mar 2006 10:36:59 +0100 (BST)

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" ( 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:

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

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 Lee                                I.T. Service          :
:  Senior Systems Programmer                Computer Centre       :
:                                           Durham University     :
:            South Road            :
:                                           Durham DH1 3LE        :
:  Phone: +44 191 334 2752                  U.K.                  :

reply via email to

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