Re: handling of missing AR

[Tim Mooney]

In regard to: Re: handling of missing AR, Ralf Wildenhues said (at 7:49am...:

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

Ralf-

These are all good points, and pretty much invalidate my argument.
Considering the (mis)uses that a few people are putting libtool to, 
it's probably best to leave things as is.

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

That's really the crux of the matter, and since it's not possible to
know whether it's going to be used, having configure error out is just
going to cause new headaches for people.

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

It's not even that I liked the idea of it erroring; I'm very experienced
with autoconf and using configure, so I personally don't like macros that
think they're smarter than the person running configure.  What I was
proposing was based on the misguided notion that configure could know if
ar would be needed, and it would be better for the package's maintainer if
the problem was caught early and configure complained loudly.  If someone
that's inexperienced is running configure and they get an obvious error
from configure that they're missing something, they're more likely to be
able to fix it themselves, which lessens the bug report load for the
package's maintainer.

> 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 `:'.

:-)  I think you've swayed me over to your side now.  It *might* be a
good idea to AC_MSG_WARN if those things aren't found, but I no longer
think it's a good idea to error out.

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