[fedfs-utils] [PATCH v2 3/8] build: avoid automake warnings about AM_PROG_AR requirement

[Chuck Lever]

On Dec 2, 2011, at 7:13 AM, Jim Meyering wrote:

> Chuck Lever wrote:
>> On Dec 1, 2011, at 7:27 AM, Jim Meyering wrote:
>>> From: Jim Meyering <meyering at redhat.com>
>>> * configure.ac: Use AM_PROG_AR (must precede LT_INIT).
>>> Without this, when using what will soon be automake-1.11.2, we'd
>>> get a warning like this for each .a file:
> ...
>> After applying this on my Fedora 15 build system, I get:
>> 
>> [cel at degas fedfs-utils]$ sh ./autogen.sh
>> cleaning up................... done
>> configure.ac:35: warning: macro `AM_PROG_AR' not found in library
> 
> I dug a little deeper and discovered that this arises from the
> combination of fedfs-utils' use of -Wall and -Werror and my use
> of almost-automake-1.11.2.  Here's a better patch:
> 
> From c3f1cfcb1506126cf56717ba22abd9537321ae7a Mon Sep 17 00:00:00 2001
> From: Jim Meyering <meyering at redhat.com>
> Date: Wed, 30 Nov 2011 20:41:48 +0100
> Subject: [PATCH] build: accommodate our use of -Wall with upcoming
> automake-1.11.2
> 
> * configure.ac: Using the -Wall option with what will soon be
> automake-1.11.2 results in a warning like this for each .a file:
>  automake: warnings are treated as errors
>  /usr/share/automake-1.11a/am/library.am: warning: `libadmin.a':\
>    linking libraries using a non-POSIX
>  /usr/share/automake-1.11a/am/library.am: archiver requires \
>    `AM_PROG_AR' in `configure.ac'
>  src/libadmin/Makefile.am:26:   while processing library `libadmin.a'
> That is due to the -Wextra-portability option implied by -Wall.
> Since AM_PROG_AR is new to automake-1.11.2, for now just disable
> the -Wextra-portability option.

Thanks for the research.  To decide whether this patch is generally applicable, I'm trying to understand how pervasive this problem is.  I think there are a few issues to consider:

  1.  Will this still be a problem once fedfs-utils is converted to build dynamic libraries instead of static libraries?

  2.  If this isn't an issue for dynamic libraries, then we only need to worry about 0.7.  Do we really need to be worried about 0.7 building without warning with a version of automake that may be released after 0.7 is EOL'd?  I suppose disabling automake's extra-portability warnings is probably harmless in that case.

  3.  Is it possible to specify a POSIX archiver for linking the static libraries instead?

  4.  Can you say a little about what we lose by disabling automake's extra-portability warnings?

> Signed-off-by: Jim Meyering <meyering at redhat.com>
> ---
> configure.ac |    5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 2a2052f..b439f3f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -34,7 +34,10 @@ AC_CONFIG_MACRO_DIR([m4])
> 
> # Automake and libtools initialization
> LT_INIT
> -AM_INIT_AUTOMAKE([-Wall -Werror silent-rules])
> +
> +# Disable the -Wextra-portability option until developers can all use
> +# automake-1.11.2 or newer, at which point we'll use the new AM_PROG_AR instead.

I'm leary of ever enabling AM_PROG_AR because, while that eliminates warnings for new versions of automake, it appears to introduce loud warnings for older versions.  This makes it somewhat not backwards compatible.  So is there ever a safe time to enable AM_PROC_AR for existing software projects?

> +AM_INIT_AUTOMAKE([-Wall -Werror silent-rules -Wno-extra-portability])
> 
> # configure command line options
> AC_ARG_WITH([fedfsuser],
> --
> 1.7.8.rc4

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com