Re: Words in configure.ac that look like macros forbidden or merely discouraged?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Words in configure.ac that look like macros forbidden or merely discouraged?

Eric Blake-3
On 06/12/2016 05:25 AM, Gavin Smith wrote:
> Hello,

Apologies for just now noticing this thread.

>
> In the Autoconf manual we read:

Any reason you mailed this to the automake list, and not autoconf, then?

>
> ====
>
> When you use the same text in a macro argument, you must therefore
> have an extra quotation level (since one is stripped away by the macro
> substitution). In general, then, it is a good idea to use double
> quoting for all literal string arguments, either around just the
> problematic portions, or over the entire argument:
>
>      AC_MSG_WARN([[AC_DC] stinks  --Iron Maiden])
>      AC_MSG_WARN([[AC_DC stinks  --Iron Maiden]])
>

>
> Note what it says: "triggers a warning". However, it seems in some
> cases, using a word that looks like it could be a macro triggers a
> hard error, not just a warning:
>
> $ autoreconf -iv
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal
> configure.ac:4: warning: macro 'AM_DC' not found in library
AM_DC is not the name used in the example, but falls into the namespace
reserved by automake, so I guess I see why you are testing it instead of
AC_DC.

> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: not using Libtool
> autoreconf: running: /usr/bin/autoconf
> configure.ac:4: error: possibly undefined macro: AM_DC
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> autoreconf: /usr/bin/autoconf failed with exit status: 1

However, the error message says that it is autoconf (not automake) that
is failing, so I don't see how this is applicable to automake.

>
> Any ideas which it is: is it actually forbidden, or should it be just a warning?

So I guess you are pointing out a documentation error in the autoconf
manual, and that the manual should call it an error, not a warning?
Sure, I can do that.

>
> I intend to put information about this here:
> http://buildsystem-manual.sourceforge.net/Macro-name-quoting.html#Macro-name-quoting
> , which I've adapted from the test in the automake manual.
>
> Contents of files:
>
> $ cat configure.ac
> AC_INIT([helloprog], [1.0])
> AM_INIT_AUTOMAKE
>
> echo AM_DC rocks
>
> AC_CONFIG_FILES([Makefile])
> AC_OUTPUT
> $ cat Makefile.am
> AUTOMAKE_OPTIONS=foreign dist-xz
> $
>
>
--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


signature.asc (617 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

[PATCH] doc: Patterns in m4_pattern_forbid cause error, not warning

Eric Blake-3
The example text regarding a desired literal AC_DC in output
claimed that the result would trigger a warning if one does
not use creative quoting; but in reality, autoconf's use of
m4_pattern_forbid to reserve the entire AC_ namespace makes
it a hard error.  Reword the section to mention the use of
m4_pattern_allow() as the fix, and beef up the example to
better demonstrate the problem.

* doc/autoconf.texi (Autoconf Language): Improve AC_DC example.
Reported by Gavin Smith <[hidden email]>.
Signed-off-by: Eric Blake <[hidden email]>
---
 doc/autoconf.texi | 29 +++++++++++++++++++----------
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 7e710a5..01a8313 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -1243,13 +1243,21 @@ Autoconf Language
                 AC_MSG_ERROR([sorry, can't do anything for you]))
 @end example

-In other cases, you may have to use text that also resembles a macro
-call.  You must quote that text even when it is not passed as a macro
-argument.  For example, these two approaches in @file{configure.ac}
-(quoting just the potential problems, or quoting the entire line) will
-protect your script in case autoconf ever adds a macro @code{AC_DC}:
+In other cases, you may want to use text that also resembles a macro
+call.  You must quote that text (whether just the potential problem, or
+the entire line) even when it is not passed as a macro argument; and you
+may also have to use @code{m4_pattern_allow} (@pxref{Forbidden
+Patterns}), to declare your intention that the resulting configure file
+will have a literal that resembles what would otherwise be reserved for
+a macro name.  For example:

 @example
+dnl Simulate a possible future autoconf macro
+m4_define([AC_DC], [oops])
+dnl Underquoted:
+echo "Hard rock was here!  --AC_DC"
+dnl Correctly quoted:
+m4_pattern_allow([AC_DC])
 echo "Hard rock was here!  --[AC_DC]"
 [echo "Hard rock was here!  --AC_DC"]
 @end example
@@ -1258,6 +1266,7 @@ Autoconf Language
 which results in this text in @file{configure}:

 @example
+echo "Hard rock was here!  --oops"
 echo "Hard rock was here!  --AC_DC"
 echo "Hard rock was here!  --AC_DC"
 @end example
@@ -1270,15 +1279,15 @@ Autoconf Language
 problematic portions, or over the entire argument:

 @example
+m4_pattern_allow([AC_DC])
 AC_MSG_WARN([[AC_DC] stinks  --Iron Maiden])
 AC_MSG_WARN([[AC_DC stinks  --Iron Maiden]])
 @end example

-However, the above example triggers a warning about a possibly
-unexpanded macro when running @command{autoconf}, because it collides
-with the namespace of macros reserved for the Autoconf language.  To be
-really safe, you can use additional escaping (either a quadrigraph, or
-creative shell constructs) to silence that particular warning:
+It is also possible to avoid the problematic patterns in the first
+place, by the use of additional escaping (either a quadrigraph, or
+creative shell constructs), in which case it is no longer necessary to
+use @code{m4_pattern_allow}:

 @example
 echo "Hard rock was here!  --AC""_DC"
--
2.9.3


Reply | Threaded
Open this post in threaded view
|

Re: Words in configure.ac that look like macros forbidden or merely discouraged?

Gavin Smith
In reply to this post by Eric Blake-3
On 22 December 2016 at 19:00, Eric Blake <[hidden email]> wrote:
> On 06/12/2016 05:25 AM, Gavin Smith wrote:
>> Hello,
>
> Apologies for just now noticing this thread.
>
>>
>> In the Autoconf manual we read:
>
> Any reason you mailed this to the automake list, and not autoconf, then?

Indeed, it doesn't need automake to fail. I used automake when I
tested this before. The following configure.ac makes autoconf give an
error message:

AC_INIT([test],[0])
AC_MSG_WARN([[AC_DC] stinks  --Iron Maiden])
AC_MSG_WARN([[AC_DC stinks  --Iron Maiden]])
AC_OUTPUT

The error is

configure.ac:2: error: possibly undefined macro: AC_DC
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

>> Any ideas which it is: is it actually forbidden, or should it be just a warning?
>
> So I guess you are pointing out a documentation error in the autoconf
> manual, and that the manual should call it an error, not a warning?
> Sure, I can do that.

Either that, or autoconf could be changed to make it a warning. I
don't see any need for that, though: I think it is okay to be an
error.

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] doc: Patterns in m4_pattern_forbid cause error, not warning

Gavin Smith
In reply to this post by Eric Blake-3
On 22 December 2016 at 19:34, Eric Blake <[hidden email]> wrote:
> The example text regarding a desired literal AC_DC in output
> claimed that the result would trigger a warning if one does
> not use creative quoting; but in reality, autoconf's use of
> m4_pattern_forbid to reserve the entire AC_ namespace makes
> it a hard error.  Reword the section to mention the use of
> m4_pattern_allow() as the fix, and beef up the example to
> better demonstrate the problem.

Thanks a lot, your changes are an improvement.