autoconf-patches
[Top][All Lists]
Advanced

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

Re: AC_PROG_WERROR


From: Akim Demaille
Subject: Re: AC_PROG_WERROR
Date: Thu, 02 Oct 2003 09:14:05 +0200
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

Please, don't include valuable material below the signature (that
part can be automatically removed by MUA when answering :).

 > Outgrowth of my earlier conversation about GCC's configury.  This
 > patch adds an AC_PROG_WERROR macro which causes all compile, link,
 > and preprocess checks to fail on warnings.

I don't like the AC_PROG prefix.  I suppose this is bound to a single
language, so AC_LANG_WERROR (with maybe something bw LANG and WERROR)
seems more appropriate.

 > How well this will work in practice, I'm not 100% sure.  My biggest
 > concern would have been the warning messages for glibc's stub
 > functions; link checks for them would go from passing to failing.
 > But there's already code to make them fail in the C compile check,
 > so I guess that's not a concern.  And the whole mode is optional
 > anyway.

 > The patch is incomplete in a few ways, I suspect:
 >   - Should ac_flag_werror be initialized somewhere?

That would be better indeed.  But why is this not bound to a language?

 >   - Should AC_PROG_CPP_WERROR be removed, since it was just added and this
 >     subsumes it?

Can someone desire the latter but not the former?

 >   - Is AC_PROG_WERROR a good name?

Nay :)

 > But other than that this patch should be OK.  I've tested that it works as
 > expected, and I can build a correct libiberty using AC_PROG_WERROR. 
 > Thoughts?

 > I have one more patch for the upcoming autoconf release.  Coming right up.

Hm...


| 2003-10-01  Daniel Jacobowitz  <address@hidden>
| 
|       * lib/autoconf/lang.m4 (AC_NO_EXECUTABLES): Try to link.  If
|       linking fails, override AC_LINK_IFELSE and AC_FUNC_MMAP.
|       
| 
| Index: lang.m4
| ===================================================================
| RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/lang.m4,v
| retrieving revision 1.165
| diff -u -p -r1.165 lang.m4
| --- lang.m4   3 Sep 2003 00:35:53 -0000       1.165
| +++ lang.m4   1 Oct 2003 23:21:56 -0000
| @@ -351,8 +351,8 @@ AC_DEFUN([AC_REQUIRE_CPP],
|  # -----------------
|  # FIXME: The GCC team has specific needs which the current Autoconf
|  # framework cannot solve elegantly.  This macro implements a dirty
| -# hack until Autoconf is abble to provide the services its users
| -# needs.
| +# hack until Autoconf is able to provide the services its users
| +# need.
|  #
|  # Several of the support libraries that are often built with GCC can't
|  # assume the tool-chain is already capable of linking a program: the
| @@ -363,26 +363,51 @@ AC_DEFUN([AC_REQUIRE_CPP],
|  # avoid the AC_PROG_CC_WORKS test, that would just abort their
|  # configuration.  The introduction of AC_EXEEXT, enabled either by
|  # libtool or by CVS autoconf, have just made matters worse.
| +#
| +# Unlike an earlier version of this macro, using AC_NO_EXECUTABLES does
| +# not disable link tests at autoconf time, but at configure time.
| +# This allows AC_NO_EXECUTABLES to be invoked conditionally.
|  AC_DEFUN_ONCE([AC_NO_EXECUTABLES],
|  [m4_divert_push([KILL])
|  
| -AC_BEFORE([$0], [_AC_COMPILER_EXEEXT_WORKS])
|  AC_BEFORE([$0], [_AC_COMPILER_EXEEXT])
| -
| -m4_define([_AC_COMPILER_EXEEXT_WORKS],
| -[cross_compiling=maybe
| -])
| +AC_BEFORE([$0], [AC_LINK_IFELSE])
|  
|  m4_define([_AC_COMPILER_EXEEXT],
| -[EXEEXT=
| -])
| +AC_LANG_CONFTEST([AC_LANG_PROGRAM()])
| +AS_IF([AC_TRY_EVAL(ac_link)], [ac_no_link=no], [ac_no_link=yes])
| +if test x$ac_no_link = xyes; then
| +  # Setting cross_compile will disable run tests; it will
| +  # also disable AC_CHECK_FILE but that's generally
| +  # correct if we can't link.
| +  cross_compiling=yes
| +  EXEEXT=
| +else
| +  m4_defn([_AC_COMPILER_EXEEXT])dnl
| +fi
| +)
|  
|  m4_define([AC_LINK_IFELSE],
| -[AC_FATAL([All the tests involving linking were disabled by $0])])
| +if test x$ac_no_link = xyes; then
| +  ac_tmp=AC
| +  AC_MSG_ERROR([Link tests are not allowed after ${ac}_NO_EXECUTABLES.])
| +fi
| +m4_defn([AC_LINK_IFELSE]))
| +
| +dnl This is a shame.  We have to provide a default for some link tests,
| +dnl similar to the default for run tests.
| +m4_define([AC_FUNC_MMAP],
| +if test x$ac_no_link = xyes; then
| +  if test "x${ac_cv_func_mmap_fixed_mapped+set}" != xset; then
| +    ac_cv_func_mmap_fixed_mapped=no
| +  fi
| +fi
| +if test "x${ac_cv_func_mmap_fixed_mapped+set}" != xset; then
| +  m4_defn([AC_FUNC_MMAP])
| +fi)

Wow.  I'm not sure I understand your code here.  You say that we
should have:


----------------------------------------------------------------------
# AC_NO_EXECUTABLES
# -----------------
# FIXME: The GCC team has specific needs which the current Autoconf
# framework cannot solve elegantly.  This macro implements a dirty
# hack until Autoconf is able to provide the services its users
# need.
#
# Several of the support libraries that are often built with GCC can't
# assume the tool-chain is already capable of linking a program: the
# compiler often expects to be able to link with some of such
# libraries.
#
# In several of these libraries, workarounds have been introduced to
# avoid the AC_PROG_CC_WORKS test, that would just abort their
# configuration.  The introduction of AC_EXEEXT, enabled either by
# libtool or by CVS autoconf, have just made matters worse.
#
# Unlike an earlier version of this macro, using AC_NO_EXECUTABLES does
# not disable link tests at autoconf time, but at configure time.
# This allows AC_NO_EXECUTABLES to be invoked conditionally.
AC_DEFUN_ONCE([AC_NO_EXECUTABLES],
[m4_divert_push([KILL])

AC_BEFORE([$0], [_AC_COMPILER_EXEEXT])
AC_BEFORE([$0], [AC_LINK_IFELSE])

m4_define([_AC_COMPILER_EXEEXT],
AC_LANG_CONFTEST([AC_LANG_PROGRAM()])
AS_IF([AC_TRY_EVAL(ac_link)], [ac_no_link=no], [ac_no_link=yes])
if test x$ac_no_link = xyes; then
  # Setting cross_compile will disable run tests; it will
  # also disable AC_CHECK_FILE but that's generally
  # correct if we can't link.
  cross_compiling=yes
  EXEEXT=
else
  m4_defn([_AC_COMPILER_EXEEXT])dnl
fi
)

m4_define([AC_LINK_IFELSE],
if test x$ac_no_link = xyes; then
  ac_tmp=AC
  AC_MSG_ERROR([Link tests are not allowed after ${ac}_NO_EXECUTABLES.])
fi
m4_defn([AC_LINK_IFELSE]))

dnl This is a shame.  We have to provide a default for some link tests,
dnl similar to the default for run tests.
m4_define([AC_FUNC_MMAP],
if test x$ac_no_link = xyes; then
  if test "x${ac_cv_func_mmap_fixed_mapped+set}" != xset; then
    ac_cv_func_mmap_fixed_mapped=no
  fi
fi
if test "x${ac_cv_func_mmap_fixed_mapped+set}" != xset; then
  m4_defn([AC_FUNC_MMAP])
fi)

m4_divert_pop()dnl
])# AC_NO_EXECUTABLES
----------------------------------------------------------------------

This is vastly underquoted: both embedded m4_define should have their
$2 in bw [].  So that ought to be something like:

m4_define([AC_LINK_IFELSE],
[if test x$ac_no_link = xyes; then
  ac_tmp=AC
  AC_MSG_ERROR([Link tests are not allowed after ${ac}_NO_EXECUTABLES.])
fi
]m4_defn([AC_LINK_IFELSE]))

And, wow, what is this mmap stuff doing here?




reply via email to

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