Re: handling of missing AR

[Ralf Wildenhues]

Hi Tim,

* Tim Mooney wrote on Thu, Mar 30, 2006 at 12:19:13AM CEST:
> In regard to: Re: handling of missing AR, Ralf Wildenhues said (at 
> 10:25pm...:
> 
> >>Shouldn't libtool's portion of configure fail in that case?
> >
> >I'm not really in favor of adding lots of failure points to macros.
[ that libtool C++/F77 issue ]

> I was actually thinking of that exact case.  ;-)  Right or wrong,
> configuring a package that used libtool 1.5.x failed for a very long time
> if there wasn't a C++ compiler installed, even if the package didn't use
> C++.  It took quite a long time before that was fixed (if it even is fixed
> in 1.5.x -- I don't know).

AFAIK that is fixed, so please file a bug report if you find out
otherwise.

> That's much more egregious, IMHO, than having configure error out because
> a tool that's absolutely needed isn't present.

Right.

> If you're saying it's not
> possible to tell at configure time whether "ar" is going to be needed,
> then I completely agree that things should be left as they are.

Right.

> If, however, we know that ar is going to be required but it's not found
> at configure time, wouldn't it be better to have configure emit an error
> message such as:

But how do you know the user will use libtool to build a library even?
I've heard of people using AC_PROG_LIBTOOL merely to get the path
hardcoding in their programs (for installed third-party packages).
There is currently a suggestion on the Automake lists to support partial
linking more conveniently, including AC_PROG_LIBTOOL to get at "ld -r".
Neither of these uses would need ar.  Or: what about the crazy package
that does not use Automake, invokes AC_PROG_LIBTOOL but uses that to
create its libraries only on a few systems (where it deems their own
shared library creation system much better)?  Yes, I remember to have
seen a similar setup.

> >See my point?  Hard failure isn't always the best thing to do, if you
> >are writing a macro to be used in other packages.  It may be different
> >if you are writing configure.ac: you know that your package will need
> >this and that, and you want early failure.
> 
> I absolutely agree with that sentiment, but I'm apparently not seeing
> how it applies in this instance.  In the situation you and I were both
> thinking of and that you describe above, libtool fails when a tool that's
> *not* explicitly needed isn't installed.  I think we both agree that's
> clearly the wrong thing to do.

My point is that you simply often can't know whether it will be used
even if you think it will.

> Here's another way to look at it.  Let's say I'm a package author, and
> my configure.ac calls the appropriate libtool macros.  If libtool's portion
> of configure doesn't error out when something that *libtool* needs isn't
> available, then doesn't that put the onus back on the package author to
> do lots of post-libtool-configure checks to make sure that AR, NM, CC, et.
> al. are defined?  Worse yet, the package maintainer now has to be concerned
> with what (libtool-specific) options were passed to configure (e.g. if
> --disable-shared was specified, then we may not need to worry about LD).
> Moreover, the package author may not have any idea what compiler toolchain
> commands are needed on some esoteric platform that he or she has never 
> seen.

Right.  I completely agree that you have a point here: it would be
better to have a configure error here for a majority of users.

> 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)

Cheers,
Ralf