On Wednesday 01 of July 2015 15:19:15 Pádraig Brady wrote:
> On 01/07/15 14:57, Pavel Raiskup wrote:
> > On Wednesday 01 of July 2015 13:42:35 Pádraig Brady wrote:
> >>>> On 01/07/15 09:00, Pavel Raiskup wrote:
> >>> This becomes painfully complicated, sorry to bothering you - just trying
> >>> to make this ARFLAGS/AR_FLAGS mess resolved. I would appreciate any help.
> >>>
> >>> Seems like the gl_PROG_AR_RANLIB was added by commit 2b14869442bc.
> >>>
> >>> Do you think the attached gnulib patches are reasonable then? First makes
> >>> the gl_PROG_AR_RANLIB a bit more conservative and the second sets the
> >>> ARFLAGS default to 'cr'.
>
> >> With this I'm now getting this warning:
> >>
> >> configure.ac:59: warning: AC_COMPILE_IFELSE was called before
> >> AC_USE_SYSTEM_EXTENSIONS
> >> ../../lib/autoconf/specific.m4:314: AC_GNU_SOURCE is expanded from...
> >> m4/gnulib-comp.m4:34: gl_EARLY is expanded from...
> >> configure.ac:59: the top level
> >>
> >> I see that gnulib-tool puts this very early on:
> >>
> >> echo " AC_REQUIRE([gl_PROG_AR_RANLIB])"
> >
> >
> > I might do something wrong, but .. Firstly I was about to think that I
> > should always AC_REQUIRE([AM_PROG_AR]) (not directly call it), however
> > that does not resolve the ordering :(.
>
> Yes the dependence is gl_PROG_AR_RANLIB -> AM_PROG_AR -> AC_COMPILE_IFELSE
> And gnulib-tool puts gl_PROG_AR_RANLIB at the start.
>
> > So to me, it rather looks (in case the gl_PROG_AR_RANLIB really has to be
> > called that early), we should also call very early
> > gl_USE_SYSTEM_EXTENSIONS (before gl_PROG_AR_RANLIB), conditionally if some
> > module requires that.
> >
> > I'm not sure whether I analyzed that correctly, but it resolved the
> > ordering for coreutils (while still calling AM_PROG_AR).
>
> That should work but seems complicated by the conditionality aspect.
Yes, there is still nothing like that in gnulib-tool, am I right? I mean
dependency among configure.ac-early snippets -- those seem to be all just
sorted by name (by 'LANG=C sort -u').
Would you consider something like this as acceptable?
diff --git a/gnulib-tool b/gnulib-tool
index ec82f35..f5bddbb 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -5188,6 +5188,10 @@ s,//*$,/,'
echo " m4_pattern_allow([^gl_ES\$])dnl a valid locale name"
echo " m4_pattern_allow([^gl_LIBOBJS\$])dnl a variable"
echo " m4_pattern_allow([^gl_LTLIBOBJS\$])dnl a variable"
+
+ echo "$final_modules" | grep "^extensions$" >/dev/null \
+ && echo " AC_REQUIRE([gl_USE_SYSTEM_EXTENSIONS])"
+
echo " AC_REQUIRE([gl_PROG_AR_RANLIB])"
if test -n "$uses_subdirs"; then
echo " AC_REQUIRE([AM_PROG_CC_C_O])"
I don't like that TBH, but if we planned to make the gl_PROG_AR_RANLIB
part of some module (and add some ordering into early snippets), this
would be enough for the meantime.
> I tested coreutils with just the s/cru/cr/ change, and it removed
> the "-u is ignored" warnings, so we can go with that one at least?
Yes. That should help gnulib projects with the 'ar' warning issue in
F22+. The AM_PROG_AR incompatibility may be fixed later..
Pavel
