[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15949: Apparently out-of-date warning
From: |
Stefano Lattarini |
Subject: |
bug#15949: Apparently out-of-date warning |
Date: |
Sun, 29 Dec 2013 23:24:36 +0100 |
On 12/27/2013 09:36 PM, Reuben Thomas wrote:
> On 26 December 2013 15:39, Stefano Lattarini <address@hidden>wrote:
>
>>
>> But AM_PROG_AR truly does not define $RANLIB itself. Perhaps you are
>> using libtool and calling AC_PROG_LIBTOOL or LT_INIT?
>
>
> Probably. So, how about changing the sentence from "should" to "may need",
>
I'd rather leave the wording as it is; the "may need" is IMHO confusing,
and I don't want to commit ourselves to specify in which exact situation
AC_PROG_RANLIB is required and when it can be dispensed with. Since
specifying AC_PROG_RANLIB even when not strictly needed turns out to be
basically a no-op and not to cause any problem, I'd leave sleeping dogs
lie, and change nothing.
> or is there some reason why AM_PROG_AR cannot AC_REQUIRE ranlib so that
> the sentence can be deleted and no action is necessary?
>
AM_PROG_AR is only required for people interested in having their package
buildable with Microsoft tools; so we can't expect all packages to use
it, and we'd still need to mandate the use AC_PROG_RANLIB for all packages
not using AM_PROG_AR. At which point, it's easier to leave documentation
and semantics as they are, IMHO.
Regards,
Stefano