| Message ID | 20230828171225.2315568-1-i.maximets@ovn.org |
|---|---|
| State | Accepted |
| Commit | 28c0cec40627b6b6277debdc8a4d3e1ef14eb502 |
| Headers | show |
| Series | [ovs-dev] configure: Avoid deprecated AC_PROG_CC_C99 if possible. | expand |
| Context | Check | Description |
|---|---|---|
| ovsrobot/apply-robot | success | apply and check: success |
| ovsrobot/github-robot-_Build_and_Test | fail | github build: failed |
| ovsrobot/intel-ovs-compilation | success | test: success |
On 28 Aug 2023, at 19:12, Ilya Maximets wrote: > autoconf 2.70 deprecated the AC_PROG_CC_C99 macro and the AC_PROG_CC > was recommended for use instead. However, older versions of that > suggested macro do not attempt enabling C99, so it is not a direct > replacement. Autoconf 2.69 and older are still widely used in many > distributions. > > Another difference is that AC_PROG_CC attempts to enable C11 in new > versions of autoconf. But since we have CI jobs that check -std=c99 > builds now, we can afford enabling C11 by default without risking > compatibility issues. > > Fix a deprecation warning by using a new AC_PROG_CC macro with > autoconf 2.70+. AC_PROG_CC and AC_PROG_CC_C99 seems to produce the > same configuration script in autoconf 2.70+ anyway, so we're already > kind of using a new macro on systems with a new autoconf. > > Signed-off-by: Ilya Maximets <i.maximets@ovn.org> This changes looks good, and had no side effects on my systems. Acked-by: Eelco Chaudron <echaudro@redhat.com>
On 8/30/23 15:11, Eelco Chaudron wrote: > > > On 28 Aug 2023, at 19:12, Ilya Maximets wrote: > >> autoconf 2.70 deprecated the AC_PROG_CC_C99 macro and the AC_PROG_CC >> was recommended for use instead. However, older versions of that >> suggested macro do not attempt enabling C99, so it is not a direct >> replacement. Autoconf 2.69 and older are still widely used in many >> distributions. >> >> Another difference is that AC_PROG_CC attempts to enable C11 in new >> versions of autoconf. But since we have CI jobs that check -std=c99 >> builds now, we can afford enabling C11 by default without risking >> compatibility issues. >> >> Fix a deprecation warning by using a new AC_PROG_CC macro with >> autoconf 2.70+. AC_PROG_CC and AC_PROG_CC_C99 seems to produce the >> same configuration script in autoconf 2.70+ anyway, so we're already >> kind of using a new macro on systems with a new autoconf. >> >> Signed-off-by: Ilya Maximets <i.maximets@ovn.org> > > This changes looks good, and had no side effects on my systems. > > Acked-by: Eelco Chaudron <echaudro@redhat.com> Thanks! Applied and backported down to 2.17 to avoid warnings. Best regards, Ilya Maximets.
diff --git a/configure.ac b/configure.ac index c8708630e..44c09b2ac 100644 --- a/configure.ac +++ b/configure.ac @@ -21,7 +21,11 @@ AC_CONFIG_HEADERS([config.h]) AC_CONFIG_TESTDIR([tests]) AM_INIT_AUTOMAKE([tar-pax]) -AC_PROG_CC_C99 +# AC_PROG_CC doesn't try enabling C99 in autoconf 2.69 and below, but +# AC_PROG_CC_C99 is deprecated in newer ones. In autoconf 2.70+ both +# will try enabling features up to C11. +m4_version_prereq([2.70], [AC_PROG_CC], [AC_PROG_CC_C99]) + AM_PROG_CC_C_O AC_PROG_CXX AC_PROG_CPP
autoconf 2.70 deprecated the AC_PROG_CC_C99 macro and the AC_PROG_CC was recommended for use instead. However, older versions of that suggested macro do not attempt enabling C99, so it is not a direct replacement. Autoconf 2.69 and older are still widely used in many distributions. Another difference is that AC_PROG_CC attempts to enable C11 in new versions of autoconf. But since we have CI jobs that check -std=c99 builds now, we can afford enabling C11 by default without risking compatibility issues. Fix a deprecation warning by using a new AC_PROG_CC macro with autoconf 2.70+. AC_PROG_CC and AC_PROG_CC_C99 seems to produce the same configuration script in autoconf 2.70+ anyway, so we're already kind of using a new macro on systems with a new autoconf. Signed-off-by: Ilya Maximets <i.maximets@ovn.org> --- configure.ac | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)