Re: AC_PROG_WERROR

[Daniel Jacobowitz]

On Thu, Oct 02, 2003 at 09:14:05AM +0200, Akim Demaille wrote:
> 
> Please, don't include valuable material below the signature (that
> part can be automatically removed by MUA when answering :).

Sorry about that.  It's convention for the GCC/GDB lists, due to a
rabid dislike of MIME on someone's part.

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

No particular reason, should it be?  It was simplest to make it
language-independent, so I did it that way.  We could use
AC_LANG_C_WERROR, but then do we add the variants for other languages
too?

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

I suppose so.

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

For the other one...

> | 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]))

My m4-fu is really, really bad.  Thank you, that works.

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

That's an unfortunate consequence of macro dependencies in libiberty. 
But I think I just realized how to get rid of it, so we don't need it
after all.  I'm testing a new patch and I'll get back to you.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer