[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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:

  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)

  This one is already obsoleted by AX_C_CHECK_FLAG et al.

  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)

  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_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 
 - For ax_check_*_flags and ax_*_check_flag I used AU_DEFUN to provide an 
   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 
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 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]