Hi Zack, thank you for all your comments, highly appreciated! > On 2023-01-10 4:25 AM, Richard Palethorpe wrote: > > > > AC_PROG_CC > > > > -# <= autoconf 2.61 doesn't have AC_PROG_AR, but 2.63 has it. Not sure about > > > > -# 2.62. > > > > +# autoconf >= v2.72a > > > This reads like we need the def for autoconf => v2.72a. How about > > You're right. I probably thought this is defined since v2.72a, > > thus not needed. > Please don't use 'v2.72a' in any commentary or tests. That version doesn't > exist yet and may never exist; if it does, it will be a short-lived beta > test release of v2.72 that we don't want people to depend on. > (Autoconf uses a very old version numbering convention in which beta tests > for release X.Y are labeled X.Ya, X.Yb, X.Yc, etc.) > Officially, AC_PROG_AR will be available as of version 2.72, and that's what > you should reference in commentary. I understood v2.72a similarly as kernel -rc1 gained new version. But sure, makes perfect sense to use final version in the comment. > > Also it looks like that redefinition is not a problem thus > > not wrapping with m4_ifndef([AC_PROG_AR]. > Autoconf will let you do that, but it's bad practice. What if version 2.73 > makes AC_PROG_AR expand to something other than > AC_CHECK_TOOL(AR, ar, :) ? You'd be overwriting whatever bug fix that was. > I suggest something like > # AC_PROG_AR was added in autoconf 2.72. > m4_ifndef([AC_PROG_AR], > [AC_DEFUN([AC_PROG_AR], [AC_CHECK_TOOL(AR, ar, :)])]) > > NOTE: missing 'ar' don't fail configure (isn't the check useless > > then?) > We don't know what you need `ar` for; it might not be appropriate to fail > the build if it's missing. You can do > AC_PROG_AR > AS_IF([test x$AR = x:], > [AC_MSG_FAILURE([no usable "ar" program detected])]) > if you want to fail the build. @Richie @Li, we obviously need ar for libs/, I'd be for this. I also have look how other check works. Kind regards, Petr > zw
