[LTP] [PATCH 1/2] configure.ac: Require 2.64

[LTP] [PATCH 1/2] configure.ac: Require 2.64

[Petr Vorel]

autoconf 2.64 is required by m4/ax_check_compile_flag.m4
(for _AC_LANG_PREFIX and AS_VAR_IF).

Testing on old distro (CentOS 6) with autoconf-2.63-5.1.el6.noarch
make autotools fails:

aclocal -I m4
configure.ac:397: error: Autoconf version 2.64 or higher is required
m4/ax_check_compile_flag.m4:39: AX_CHECK_COMPILE_FLAG is expanded from...
configure.ac:397: the top level
autom4te: /usr/bin/m4 failed with exit status: 63
aclocal: autom4te failed with exit status: 63
make: *** [aclocal.m4] Error 63

Fixes: a08cbaea73 ("Add AX_CHECK_COMPILE_FLAG() autoconf macro")

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 1ab7cc60da..c2b0f48e79 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,4 +1,4 @@
-AC_PREREQ(2.61)
+AC_PREREQ(2.64)
 AC_INIT([ltp], [LTP_VERSION], [ltp@lists.linux.it])
 AC_CONFIG_AUX_DIR([.])
 AM_INIT_AUTOMAKE
-- 
2.39.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

[LTP] [PATCH 2/2] configure.ac: Update AC_PROG_AR related comment

[Petr Vorel]

AC_PROG_AR was added much later: in v2.72a [1]. Also it looks like that
redefinition is not a problem thus not wrapping with m4_ifndef([AC_PROG_AR].

NOTE: missing 'ar' don't fail configure (isn't the check useless then?):
$ rm -rf autom4te.cache/; ma autotools && ./configure; echo $?
...
configure:4878: checking for ar
configure:4913: result: no
...
0

[1] https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=c48fdb81191c8b7c7c0dde6141b861b178a6a284

Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
 configure.ac                    | 3 +--
 testcases/realtime/configure.ac | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index c2b0f48e79..edf00687f2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,8 +20,7 @@ AM_MAINTAINER_MODE([enable])
 AC_CANONICAL_HOST
 
 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
 AC_DEFUN([AC_PROG_AR], [AC_CHECK_TOOL(AR, ar, :)])
 AC_PROG_AR
 AC_PROG_RANLIB
diff --git a/testcases/realtime/configure.ac b/testcases/realtime/configure.ac
index 6f50f1490f..39f16f1779 100644
--- a/testcases/realtime/configure.ac
+++ b/testcases/realtime/configure.ac
@@ -12,8 +12,7 @@ AC_CHECK_HEADERS_ONCE([ \
 AC_CANONICAL_HOST
 
 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
 AC_DEFUN([AC_PROG_AR], [AC_CHECK_TOOL(AR, ar, :)])
 AC_PROG_AR
 AC_PROG_RANLIB
-- 
2.39.0


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/2] configure.ac: Require 2.64

[Petr Vorel]

Hi,

tested:
https://github.com/pevik/ltp/actions/runs/3829553464

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/2] configure.ac: Require 2.64

[Li Wang]

Hi Petr,

I see other places also used 2.61, do you think we need to correct them as
well?
(e.g. open-posix and realtime)

$ git grep AC_PREREQ
configure.ac:AC_PREREQ(2.61)
testcases/open_posix_testsuite/configure.ac:AC_PREREQ(2.61)
testcases/realtime/configure.ac:AC_PREREQ(2.61)



On Tue, Jan 3, 2023 at 8:45 PM Petr Vorel <pvorel@suse.cz> wrote:

> autoconf 2.64 is required by m4/ax_check_compile_flag.m4
> (for _AC_LANG_PREFIX and AS_VAR_IF).
>
> Testing on old distro (CentOS 6) with autoconf-2.63-5.1.el6.noarch
> make autotools fails:
>
> aclocal -I m4
> configure.ac:397: error: Autoconf version 2.64 or higher is required
> m4/ax_check_compile_flag.m4:39: AX_CHECK_COMPILE_FLAG is expanded from...
> configure.ac:397: the top level
> autom4te: /usr/bin/m4 failed with exit status: 63
> aclocal: autom4te failed with exit status: 63
> make: *** [aclocal.m4] Error 63
>
> Fixes: a08cbaea73 ("Add AX_CHECK_COMPILE_FLAG() autoconf macro")
>
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 1ab7cc60da..c2b0f48e79 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1,4 +1,4 @@
> -AC_PREREQ(2.61)
> +AC_PREREQ(2.64)
>  AC_INIT([ltp], [LTP_VERSION], [ltp@lists.linux.it])
>  AC_CONFIG_AUX_DIR([.])
>  AM_INIT_AUTOMAKE
> --
> 2.39.0
>
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
>
>

-- 
Regards,
Li Wang

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/2] configure.ac: Require 2.64

[Petr Vorel]

Hi Li,

> Hi Petr,

> I see other places also used 2.61, do you think we need to correct them as
> well?
> (e.g. open-posix and realtime)

> $ git grep AC_PREREQ
> configure.ac:AC_PREREQ(2.61)
> testcases/open_posix_testsuite/configure.ac:AC_PREREQ(2.61)
> testcases/realtime/configure.ac:AC_PREREQ(2.61)

Sure, I could do that, but these independent projects actually work with older
version, that's why I didn't do that.

FYI realtime will go away, once I find time to port relevant tests to rt_tests
and openposix could one day become in separate git.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/2] configure.ac: Require 2.64

[Li Wang]

Petr Vorel <pvorel@suse.cz> wrote:

Hi Li,
>
> > Hi Petr,
>
> > I see other places also used 2.61, do you think we need to correct them
> as
> > well?
> > (e.g. open-posix and realtime)
>
> > $ git grep AC_PREREQ
> > configure.ac:AC_PREREQ(2.61)
> > testcases/open_posix_testsuite/configure.ac:AC_PREREQ(2.61)
> > testcases/realtime/configure.ac:AC_PREREQ(2.61)
>
> Sure, I could do that, but these independent projects actually work with
> older
> version, that's why I didn't do that.
>

Ok, as long as we build it internally of LTP, that is required because
we have to check the configuration at top-level and then go into the
subproject. It will use the upper version first.


>
> FYI realtime will go away, once I find time to port relevant tests to
> rt_tests
> and openposix could one day become in separate git.
>

If so, that older version will be tolerated. Thanks!

For both:
Reviewed-by: Li Wang <liwang@redhat.com>

-- 
Regards,
Li Wang

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 2/2] configure.ac: Update AC_PROG_AR related comment

[Richard Palethorpe]

Hello,

Petr Vorel <pvorel@suse.cz> writes:

> AC_PROG_AR was added much later: in v2.72a [1]. Also it looks like that
> redefinition is not a problem thus not wrapping with m4_ifndef([AC_PROG_AR].
>
> NOTE: missing 'ar' don't fail configure (isn't the check useless then?):
> $ rm -rf autom4te.cache/; ma autotools && ./configure; echo $?
> ...
> configure:4878: checking for ar
> configure:4913: result: no
> ...
> 0
>
> [1] https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=c48fdb81191c8b7c7c0dde6141b861b178a6a284
>
> Signed-off-by: Petr Vorel <pvorel@suse.cz>
> ---
>  configure.ac                    | 3 +--
>  testcases/realtime/configure.ac | 3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index c2b0f48e79..edf00687f2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -20,8 +20,7 @@ AM_MAINTAINER_MODE([enable])
>  AC_CANONICAL_HOST
>  
>  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

# for autoconfig < v2.72a

Also which distro(s) do we support which have < v2.72a? We maybe can
include that here *if known*.

>  AC_DEFUN([AC_PROG_AR], [AC_CHECK_TOOL(AR, ar, :)])
>  AC_PROG_AR
>  AC_PROG_RANLIB
> diff --git a/testcases/realtime/configure.ac b/testcases/realtime/configure.ac
> index 6f50f1490f..39f16f1779 100644
> --- a/testcases/realtime/configure.ac
> +++ b/testcases/realtime/configure.ac
> @@ -12,8 +12,7 @@ AC_CHECK_HEADERS_ONCE([ \
>  AC_CANONICAL_HOST
>  
>  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
>  AC_DEFUN([AC_PROG_AR], [AC_CHECK_TOOL(AR, ar, :)])
>  AC_PROG_AR
>  AC_PROG_RANLIB
> -- 
> 2.39.0


-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 1/2] configure.ac: Require 2.64

[Richard Palethorpe]

Hello,

Merged, thanks!

Li Wang <liwang@redhat.com> writes:

> Petr Vorel <pvorel@suse.cz> wrote:
>
> Hi Li,
>>
>> > Hi Petr,
>>
>> > I see other places also used 2.61, do you think we need to correct them
>> as
>> > well?
>> > (e.g. open-posix and realtime)
>>
>> > $ git grep AC_PREREQ
>> > configure.ac:AC_PREREQ(2.61)
>> > testcases/open_posix_testsuite/configure.ac:AC_PREREQ(2.61)
>> > testcases/realtime/configure.ac:AC_PREREQ(2.61)
>>
>> Sure, I could do that, but these independent projects actually work with
>> older
>> version, that's why I didn't do that.
>>
>
> Ok, as long as we build it internally of LTP, that is required because
> we have to check the configuration at top-level and then go into the
> subproject. It will use the upper version first.
>
>
>>
>> FYI realtime will go away, once I find time to port relevant tests to
>> rt_tests
>> and openposix could one day become in separate git.
>>
>
> If so, that older version will be tolerated. Thanks!
>
> For both:
> Reviewed-by: Li Wang <liwang@redhat.com>
>
> -- 
> Regards,
> Li Wang


-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 2/2] configure.ac: Update AC_PROG_AR related comment

[Petr Vorel]

Hi Richie,

thanks for your review.

> >  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.

> # for autoconfig < v2.72a
This is much better, I'll merge it as this (unless anybody objects).

> Also which distro(s) do we support which have < v2.72a? We maybe can
> include that here *if known*.

I'm not sure if v2.72a (alpha?) is shipped to any distro. v2.72 haven't been
released yet.

The reason to update the comment was
1) don't confuse with very old version (it's still needed)
2) notify users once v2.72 is released and shipped in case of problems.

Kind regards,
Petr

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 2/2] configure.ac: Update AC_PROG_AR related comment

[Zack Weinberg]

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.

 > 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.

zw

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 2/2] configure.ac: Update AC_PROG_AR related comment

[Petr Vorel]

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

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp

Re: [LTP] [PATCH 2/2] configure.ac: Update AC_PROG_AR related comment

[Richard Palethorpe]

Hello,

Petr Vorel <pvorel@suse.cz> writes:

> 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.

Sure, also I'll set this to "changes requested" in Patchwork.

>
> Kind regards,
> Petr
>
>> zw


-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp