[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal to make better use of 5th arg to AC_CHECK_LIB and AC_SEARCH
From: |
Paul Eggert |
Subject: |
Re: Proposal to make better use of 5th arg to AC_CHECK_LIB and AC_SEARCH_LIBS |
Date: |
Mon, 1 Oct 2001 12:47:24 -0700 (PDT) |
> From: Rainer Orth <address@hidden>
> Date: Mon, 1 Oct 2001 20:40:01 +0200 (MEST)
>
> AC_CHECK_LIB(hesiod, hes_init,,, -lresolv)
How about using something like this instead?
AC_SEARCH_LIBS(hes_init, hesiod,,
[AC_SEARCH_LIBS(hes_init, hesiod,,, -lresolv])])
> * It should first try to link *without* -lresolv and see if this succeeds.
> If this works, all is fine and LIBS can be set to just -lhesiod as
> before.
Wouldn't it be better to try to link without either -lresolv or
-lhesiod first? After all, if hes_init is in the standard library,
you wouldn't want to bother with -lhesiod. The AC_SEARCH_LIBS snippet
above does this.
> * If this first attempt fails, a second attempt should be made with *both*
> -lhesiod and -lresolv on the link line. If this succeeds, both -lhesiod
> and -lresolv should be added to LIBS.
What if there were multiple -lxxx args, e.g.: AC_CHECK_LIB(hesiod,
hes_init,,, -lresolv -lsocket) Would you want it to try all
combinations ('', '-lresolv', '-lsocket', '-lresolve -lsocket')?
Seems like that would be a win in some cases.
My own impression is that there are a lot of possibilities here. I
agree that AC_CHECK_LIB does not have good semantics. However, I
think your proposal might be improved and/or generalized too. If it's
an incompatible change, I'd rather see an improved/generalized
proposal now rather than install one incompatible change now, and
another one later.