[+cc Ralf]
On Friday 27 of March 2015 21:43:14 Pavel Raiskup wrote:
> On Friday 27 of March 2015 10:51:36 Eric Blake wrote:
> > Hmm. How hard is it to change ARFLAGS to 'cr' instead of the default of
> > 'cru', so that projects that want to silence the warning now can do so
> > without waiting on automake to catch up? (Remember, the warning is live
> > on rawhide systems now, and even if we release a new automake with a
> > patch to change the default, there are TONS of packages built with older
> > automake that will still warn until such time as autoreconf is run on
> > those packages to update them to the newer automake)
>
> Agreed here, while trying to look at possible patch, I found that libtool
> historically does not respect automake's ARFLAGS, it has its own AR_FLAGS:
> http://lists.gnu.org/archive/html/libtool/2008-05/msg00050.html
> So fixing automake does not help for libtool-enabled projects, and, in some
> situations users could need AR_FLAGS=X ARFLAGS=X, but yes - still easy to
> define on per-project basis.
>
> FTR, Libtool uses AR_FLAGS from ~2000 (commit 8300de4c54e6f04f0d), automake
> ARFLAGS from ~2003 (commit a71b3490639831ca).
>
> This is probably different issue, but sync is needed.. having two variables
> doing the same is pain. What about make libtool respect the ARFLAGS also
> even though it is younger variable? Just because ARFLAGS looks more
> consistently with other *FLAGS. The proposal would be to make ARFLAGS and
> AR_FLAGS synonyms (possibly marking AR_FLAGS obsoleted). Could we do the
> same for automake?
Sorry for the delay. I tried to look at it, but I accidentally found the
old topic: https://www.mail-archive.com/bug-libtool@gnu.org/msg01198.html
.. where Ralf describes that we should be careful of merging ARFLAGS and
AR_FLAGS variables - but I don't understand it correctly, tbh:
On Mon, 20 Aug 2007 14:00:21 -0700 Ralf Wildenhues wrote:
> Ah, so the chance of reconciliation with Automake's ARFLAGS just got a
> wee bit better. Except that Automake uses
> $(AR) $(ARFLAGS) LIBRARY OBJECTS...
>
> and Libtool would like to not have a space after ${ARFLAGS}, if it wants
> to support the w32 LIB program.
Because within actual Libtool, if there is $AR_FLAGS used there is always
something like '$AR<space>$AR_FLAGS<space>...'. It means the space _is_
already there.
Why would user want to use 'make "ARFLAGS=cru "' (I mean calling something
like 'ar "cru " ...'), Ralf? Or anybody?
I tried to prepare the patch, but thats probably wrong. It would be nice
if somebody could comment,
Thanks, Pavel
>From e42bf7080e08a3216fe5c496ffd9e7ec66ecdd04 Mon Sep 17 00:00:00 2001
From: Pavel Raiskup <prais...@redhat.com>
Date: Fri, 17 Apr 2015 15:05:42 +0200
Subject: [PATCH 1/2] libool.m4: incorporate ARFLAGS variable
Based on quick observation, Libtool has used AR_FLAGS since ~2000
(commit 8300de4c54e6f04f0d), Automake ARFLAGS from ~2003 (commit
a71b3490639831ca). Even though ARFLAGS is younger, it sounds like
more consistent naming according to variables like LDFLAGS,
CFLAGS, etc.
For now, take the ARFLAGS as equivalent for AR_FLAGS, don't change
internal code to use ARFLAGS also. Also, make the value of
ARFLAGS overridable during libtool run-time.
---
NEWS | 5 +++++
m4/libtool.m4 | 17 +++++++++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/NEWS b/NEWS
index c5c9023..f9b863b 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,11 @@ NEWS - list of user-visible changes between releases of GNU Libtool
* Noteworthy changes in release ?.? (????-??-??) [?]
+** New features:
+
+ - libtool script and libtool.m4 now supports ARFLAGS variable name
+ that should in long term replace AR_FLAGS (to be consistent
+ with Automake)
* Noteworthy changes in release 2.4.6 (2015-02-15) [stable]
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index a3bc337..26b7530 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -1493,9 +1493,22 @@ need_locks=$enable_libtool_lock
m4_defun([_LT_PROG_AR],
[AC_CHECK_TOOLS(AR, [ar], false)
: ${AR=ar}
-: ${AR_FLAGS=cru}
_LT_DECL([], [AR], [1], [The archiver])
-_LT_DECL([], [AR_FLAGS], [1], [Flags to create an archive])
+
+# Use ARFLAGS variable as AR's operation code to sync the variable naming with
+# Automake. If both AR_FLAGS and ARFLAGS are specified, AR_FLAGS should have
+# higher priority because thats what people were doing historically (setting
+# ARFLAGS for automake and AR_FLAGS for libtool). FIXME: Make the AR_FLAGS
+# variable obsoleted/removed.
+
+: ${AR_FLAGS=${ARFLAGS-cru}}
+lt_ar_flags="$AR_FLAGS"
+_LT_DECL([], [lt_ar_flags], [0], [Flags to create an archive (by configure)])
+
+# Make AR_FLAGS overridable by 'make ARFLAGS='. Don't try to run-time override
+# by AR_FLAGS because that was never working and AR_FLAGS is about to die.
+_LT_DECL([], [AR_FLAGS], [\${ARFLAGS-"\$lt_ar_flags"}],
+ [Flags to create an archive])
AC_CACHE_CHECK([for archiver @FILE support], [lt_cv_ar_at_file],
[lt_cv_ar_at_file=no
--
2.1.0
