Patches for implementing checking for valid CFLAGS, LDFLAGS, etc.

From:

Maarten Bosmans

Subject:

Patches for implementing checking for valid CFLAGS, LDFLAGS, etc.

Date:

Mon, 20 Jun 2011 11:24:03 +0200

There are a lot of macros dealing with checking which flags can be used with the
compiler (or other tools), all subtly different. I set out to analyse the
advantages and disadvantages of each and use that to write an implementation
that can be used to replace them all.
These are the relevant existing files:
ax_c_check_flag.m4
ax_cpp_check_flag.m4
ax_cxx_check_flag.m4
ax_cxxcpp_check_flag.m4
ax_ld_check_flag.m4
These macros are basically checks for preprocessor/compiler/linker flags for
different languages. I think a better approach would be to let the user set
the language with AC_LANG_PUSH/POP and in the macro just check with the
current language's settings.
The macros neeedlessy use a SED invocation to generate a cache variable name,
where something like AS_VAR_PUSHDEF would be much better.
The BODY and PROLOGUE arguments that are used in the call to AC_LANG_PROGRAM
appear not to be used by anyone. (according to a Google Code search)
ax_gcc_option.m4
This one is already obsoleted by AX_C_CHECK_FLAG et al.
ax_cflags_aix_option.m4
ax_cflags_gcc_option.m4
ax_cflags_hpux_option.m4
ax_cflags_irix_option.m4
ax_cflags_sun_option.m4
These files have copies of macros for C/CXX and old/new variable ordering.
There are 20 variants of the same 30-line macro. The macros are well-written,
but the use of the for-loop with string splitting on % using sed is a bit hard
to follow when reading the code.
The main advantage of these macros is that they know which command line option
to add to force a bad flag to throw an error. It would be great though if the
user of the macro does not have to know which compiler flavour is being used,
but that the right one was chosen automatically. (this is not part of this
patch series, but could be done based on the code in ax_cflags_warn_all.m4)
ax_check_compiler_flags.m4
ax_check_linker_flags.m4
There is some duplicate code here to deal with non-literal variable names that
can be better handled by AS_VAR_PUSHDEF.
The main oddity of these macros is that the check only for the given FLAG, not
for the FLAG in addition to the default CFLAGS. I think this is not the
behaviour normally wanted, but this behaviour is kept in this patch by setting
the CFLAGS empty temporarily.
The first two commits only remove the redundancy in ax_cflags_*_option.m4:
m4/ax_cflags_aix_option.m4 | 125 ++++------------------------------------
m4/ax_cflags_gcc_option.m4 | 133 ++++--------------------------------------
m4/ax_cflags_hpux_option.m4 | 125 ++++------------------------------------
m4/ax_cflags_irix_option.m4 | 125 ++++------------------------------------
m4/ax_cflags_sun_option.m4 | 128 ++++-------------------------------------
5 files changed, 65 insertions(+), 571 deletions(-)
The following five introduce ax_check_flag.m4 and base the implementation of the
existing macros on that.
m4/ax_c_check_flag.m4 | 50 ++++----------
m4/ax_cflags_aix_option.m4 | 31 ++-------
m4/ax_cflags_gcc_option.m4 | 35 ++--------
m4/ax_cflags_hpux_option.m4 | 31 ++-------
m4/ax_cflags_irix_option.m4 | 31 ++-------
m4/ax_cflags_sun_option.m4 | 32 ++--------
m4/ax_check_compiler_flags.m4 | 43 +++++-------
m4/ax_check_flag.m4 | 148 +++++++++++++++++++++++++++++++++++++++++
m4/ax_check_linker_flags.m4 | 40 ++++-------
m4/ax_cpp_check_flag.m4 | 50 ++++----------
m4/ax_cxx_check_flag.m4 | 50 ++++----------
m4/ax_cxxcpp_check_flag.m4 | 50 ++++----------
m4/ax_ld_check_flag.m4 | 49 +++----------
13 files changed, 275 insertions(+), 365 deletions(-)
Is this the right approach to take?
Specifically, I have some questions:
- The implementation of the new macros is partly based on
AX_CHECK_COMPILER_FLAGS and
AX_CFLAGS_GCC_OPTION. Therefor I retained some copyright from those in the
new macro,
is this right?
- There are some AX_APPEND_* macros added, should these be in the same file or
separate?
- For ax_check_*_flags and ax_*_check_flag I used AU_DEFUN to provide an
implementation
based on the new macros that is automatically updated when running
autoupdate. Is this
the right approach, or should I leave the deprecated macros as the were and
only add a
message on top of the description?
I think the most useful addition is that it is now possible to do
AX_APPEND_COMPILE_FLAGS([-Wno-long-long -Wvla -Wno-overlength-strings])
and the flags that pass the test are automatically appended to the CFLAGS. This
is
functionality that is implemented quite often, but was not in the autoconf
archive yet.
For a future enhancement it would be great of some flags for making warnings
fatal, like
is done in ax_cflags_gcc_option.m4 et al., could be used automatically in these
checks.
Maarten