[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bug#395466: AM_PATH_CHECK causes "possibly undefined macro" errors
From: |
Josh Triplett |
Subject: |
Re: Bug#395466: AM_PATH_CHECK causes "possibly undefined macro" errors |
Date: |
Fri, 27 Oct 2006 14:02:18 -0700 |
User-agent: |
Thunderbird 1.5.0.7 (X11/20060927) |
Ralf Wildenhues wrote:
> [ http://bugs.debian.org/395466 ]
>
> Hello Josh,
>
> * Josh Triplett wrote on Fri, Oct 27, 2006 at 09:33:30AM CEST:
>> --- check.m4.orig 2006-10-13 12:24:41.000000000 -0700
>> +++ check.m4 2006-10-26 23:55:54.000000000 -0700
>> @@ -4,8 +4,9 @@
>>
>> AC_DEFUN([AM_PATH_CHECK],
>> [
>> - AC_MSG_WARN([[AM_PATH_CHECK() is deprecated]])
>> - AC_MSG_WARN([[use PKG_CHECK_MODULES([CHECK], [check >= 0.9.4]) instead]])
>> + empty=
>> + AC_MSG_WARN([A${empty}M_PATH_CHECK() is deprecated])
>> + AC_MSG_WARN([[use P${empty}KG_CHECK_MODULES([CHECK], [check >= 0.9.4])
>> instead]])
>> AC_ARG_WITH([check],
>> [ --with-check=PATH prefix where check is installed
>> [default=auto]])
>>
>
> Yuck three times. 1. Learn to use Quadrigraphs:
> AC_MSG_WARN([[AM@&address@hidden() is deprecated]])
>
> http://www.gnu.org/software/autoconf/manual/html_node/Quadrigraphs.html
Ah, much better, thanks. This change seems to work, and has the additional
advantage of not affecting the generated configure script. Revised patch
attached.
> 2. Double quotation [[ ]] does successfully prevent expansion of macros,
> iff all macros calling this one have been quoted correctly, i.e., once.
In this case, only the top-level configure.ac calls AM_PATH_CHECK, and it
just includes a line "AM_PATH_CHECK", with no quoting. The double
quotation did successfully prevent macro expansion; it just didn't prevent
autoconf from noticing those unexpanded macro names and complaining about
them.
> 3. m4_pattern_forbid was invented to forbid some patterns. User macros
> should simply not begin with 'AM_'. That prefix is reserved for
> Automake, and also used by a set of legacy macros from some other
> packages. When you invent new names, use a different prefix, like
> 'jt_', or, for pkg-config, 'PKG_'. I reckon that the damage is already
> done with AM_PATH_CHECK though. Which is the name of the package that
> defines it? It is broken, the bug should be moved to this package, and
> to fix it, the package should add something like
> m4_pattern_allow([^AM_PATH_CHECK$])
> to its macro.
The check package defined AM_PATH_CHECK, and has now deprecated it in
favor of a pkg-config file and the use of PKG_CHECK_MODULES as the
warning message indicates. However, existing software using check relies
on the current AM_PATH_CHECK macro.
m4_pattern_allow seems like the wrong approach here, for two reasons:
* In order to solve this bug, check.m4 would need to use
m4_pattern_allow for PKG_CHECK_MODULES as well, which seems very wrong.
* m4_pattern_allow would disable the normal behavior of complaining about
unexpanded symbols in these two cases, which could leave errors undetected
at autoconf time, and generate a broken configure script with these macros
unexpanded in other places.
I think your suggested quadrigraph solution works best in this case.
- Josh Triplett
--- check.m4.orig 2006-10-13 12:24:41.000000000 -0700
+++ check.m4 2006-10-27 13:38:23.000000000 -0700
@@ -4,8 +4,8 @@
AC_DEFUN([AM_PATH_CHECK],
[
- AC_MSG_WARN([[AM_PATH_CHECK() is deprecated]])
- AC_MSG_WARN([[use PKG_CHECK_MODULES([CHECK], [check >= 0.9.4]) instead]])
+ AC_MSG_WARN([A@&address@hidden() is deprecated])
+ AC_MSG_WARN([[use P@&address@hidden([CHECK], [check >= 0.9.4]) instead]])
AC_ARG_WITH([check],
[ --with-check=PATH prefix where check is installed [default=auto]])
signature.asc
Description: OpenPGP digital signature