Re: handling of missing AR

[Tim Mooney]

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.
> Sure, there are some hideous cases (missing `file' on Cygwin is, umm,
> leads to rather unobvious issues, for example), but this one isn't:
> the build will obviously fail the first time the missing tool is used.
>
> Here's a bit of hand-waving why I'm not too fond of hard failures:
> Completely orthogonal to this issue at hand, there was last week a bug
> report on one of the Autoconf lists: all but the first-invoked of the
> macros AC_PROG_CC, AC_PROG_CXX, AC_PROG_F77 would not cause a configure
> error if the macro won't find a suitable compiler.  That lead to weird
> followup decisions of the configure script.  Looking into a fix, let's
> remember that Libtool-1.5.x (but not CVS HEAD) unfortunately has that
> bug that it unconditionally calls all of the above, even if the
> respective languages are not used at all.  So users of packages that
> don't come anywhere near Fortran would need to install a Fortran
> compiler to be able to successfully run `configure'.  Tell that to
> someone with a system where there is no such thing as a Fortran
> compiler.

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

That's much more egregious, IMHO, than having configure error out because
a tool that's absolutely needed isn't present.  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.

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:

configure: error: An "ar" command is required for building static libraries.
configure with --disable-static if you have no "ar" command.

than having the build fail partway through, with an error that's much
less obvious to someone that's not an experienced user?

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

However, in this situation libtool is detecting that a tool isn't present
but allowing configure to proceed.  If libtool's configure macro knew at
that point that "ar" was needed but no "ar" was found, isn't it doing
the wrong thing by allowing things to proceed?

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.
That's why the author is using libtool -- so their package supports both
archive and shared libraries on multiple esoteric platforms, without the
package author having to worry about the details of how it's done or whether
the person running configure only wants one or the other type of libraries.

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?

> Hope this helps a bit.

Your libtool posts are always helpful, even when I don't agree with them.
;-)

Tim
--
Tim Mooney                              address@hidden
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164