[+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