GNU bug report logs - #15949
Apparently out-of-date warning

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15949 in the body.
You can then email your comments to 15949 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-automake <bug-automake <at> gnu.org>
Subject: Apparently out-of-date warning
Date: Thu, 21 Nov 2013 22:05:26 +0000

[Message part 1 (text/plain, inline)]

I am using automake 1.13.3. I noticed in the manual the following sentence
in the section on building static libraries, which I do for my project with
libgnu.a:

You should call 'AC_PROG_RANLIB' from your 'configure.ac' to define
'RANLIB' (Automake will complain otherwise).

I call AM_PROG_AR, and as far as I can see from the placement in my
generated configure, that seems to be sufficient to define RANLIB;
AC_PROG_RANLIB doesn't seem to be needed. At least, I get no errors, and
the library is built.

Can this sentence therefore be removed from the manual? I checked, and it
is still present in current git.

-- 
http://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Message #8 received at 15949 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 15949 <at> debbugs.gnu.org
Subject: Re: bug#15949: Apparently out-of-date warning
Date: Thu, 26 Dec 2013 16:39:24 +0100

tags 15949 + notabug
close 15949
thanks

On 11/21/2013 11:05 PM, Reuben Thomas wrote:
> I am using automake 1.13.3. I noticed in the manual the following sentence
> in the section on building static libraries, which I do for my project with
> libgnu.a:
> 
> You should call 'AC_PROG_RANLIB' from your 'configure.ac' to define
> 'RANLIB' (Automake will complain otherwise).
> 
> I call AM_PROG_AR, and as far as I can see from the placement in my
> generated configure, that seems to be sufficient to define RANLIB;
> AC_PROG_RANLIB doesn't seem to be needed. At least, I get no errors, and
> the library is built.
>
But AM_PROG_AR truly does not define $RANLIB itself.  Perhaps you are
using libtool and calling AC_PROG_LIBTOOL or LT_INIT?  This would
exaplain your situation, since those macros call AC_REQUIRE on
AC_PROG_RANLIB (or define $RANLIB in a way similar to how AC_PROG_RANLIB
does it, I don't remember the exact details now).

> Can this sentence therefore be removed from the manual? I checked, and it
> is still present in current git.
> 
Give the above, I'd rather leave the sentence there :-)
Closing this bug.

Regards,
  Stefano

Message #15 received at 15949 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 15949 <at> debbugs.gnu.org
Subject: Re: bug#15949: Apparently out-of-date warning
Date: Fri, 27 Dec 2013 20:36:09 +0000

[Message part 1 (text/plain, inline)]

On 26 December 2013 15:39, Stefano Lattarini <stefano.lattarini <at> gmail.com>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",
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?

[Message part 2 (text/html, inline)]

Message #18 received at 15949 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 15949 <at> debbugs.gnu.org
Subject: Re: 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 <stefano.lattarini <at> gmail.com>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

Message #21 received at 15949 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 15949 <at> debbugs.gnu.org
Subject: Re: bug#15949: Apparently out-of-date warning
Date: Sun, 29 Dec 2013 22:57:45 +0000

[Message part 1 (text/plain, inline)]

On 29 December 2013 22:24, Stefano Lattarini <stefano.lattarini <at> gmail.com>wrote:

> AM_PROG_AR is only required for people interested in having their package
> buildable with Microsoft tools


And we can't make "AM_PROG_AR" an automatic default? What would be the
downside?

(Sorry if I'm being a pain, but I find autotools a painful time sink, and I
use it for many projects; anything that can be done to simplify it, however
slightly, is a boon to both those of us who use it and those who refuse to
on the grounds of excessive complexity and crankiness, with whom I all too
often find myself sympathising!)

-- 
http://rrt.sc3d.org

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.