On 01/07/15 16:22, Pavel Raiskup wrote: > 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.
Yes that's a bit coupled but should work. I'll try to test later. >> 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.. thanks, Pádraig.
