Re: autoconf 2.61: AC_DEFINE variable with parenthesis
Paul Eggert wrote: OK, thanks, I installed that, after tightening up the documentation a bit. Here's the documentation patch I installed. Great! A note in NEWS might be worthwhile as well.
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
OK, thanks, I installed that, after tightening up the documentation
a bit. Here's the documentation patch I installed.
--- autoconf.texi.~1.1120~ 2006-12-28 22:17:02.0 -0800
+++ autoconf.texi 2006-12-28 22:40:28.0 -0800
@@ -8252,8 +8252,15 @@ output.
@defmacx AC_DEFINE (@var{variable})
@acindex{DEFINE}
Define @var{variable} to @var{value} (verbatim), by defining a C
-object-like macro for @var{variable}. @var{variable} should be a C
-identifier that contains only letters, digits, and underscores.
+preprocessor macro for @var{variable}. @var{variable} should be a C
+identifier, optionally suffixed by a parenthesized argument list to
+define a C preprocessor macro with arguments. The macro argument list,
+if present, should be a comma-separated list of C identifiers, possibly
+terminated by an ellipsis @samp{...} if C99 syntax is employed.
[EMAIL PROTECTED] should not contain comments, white space, trigraphs,
+backslash-newlines, universal character names, or [EMAIL PROTECTED]
+characters.
+
@var{value} should not contain literal newlines, and if you are not
using @code{AC_CONFIG_HEADERS} it should not contain any @samp{#}
characters, as @command{make} tends to eat them. To use a shell variable,
@@ -8276,6 +8283,10 @@ is obsolescent and may be withdrawn in f
If the @var{variable} is a literal string, it is passed to
@code{m4_pattern_allow} (@pxref{Forbidden Patterns}).
+
+If multiple @code{AC_DEFINE} statements are executed for the same
[EMAIL PROTECTED] name (not counting any parenthesized argument list),
+the last one wins.
@end defmac
@defmac AC_DEFINE_UNQUOTED (@var{variable}, @var{value}, @ovar{description})
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
Paul Eggert wrote: Paul Eggert wrote: That could well be, but it was never documented and it's not clear to me what the semantics would be. Are arbitrary characters allowed in the macro name? Surely not. No, just things that are valid in cpp #defines. Surely that's too strong as well. Are ellipses ... allowed? How about C comments, Universal Character Names and UTF-8 in names? Or backslash-newline, which can occur between any two pairs of characters in the above? Or trigraphs lke ??= and ??/? These are all valid in cpp #defines, before the ) that closes the argument list. This stuff can get hairy pretty quickly, which is why we'd need to document exactly what we support, if we want to support it. If you want to restrict us to the minimal useful subset in order to make autoconf's limited parsing of the AC_DEFINE arguments more convenient, why not say that the characters must be in [A-Za-z0-9_,()], and must form a valid cpp identifier and (optionally) a valid cpp argument list? (Ellipses are a C99 feature and it would not be a good idea to point users to them in a config.h file.) What happens if we have AC_DEFINE([NAME(x)], ...) followed by AC_DEFINE([NAME(y)], ...) followed by AC_DEFINE([NAME], ...)? The same thing that happens if you do AC_DEFINE([NAME],[VAL1]) followed by AC_DEFINE([NAME],[VAL2]): the last definition encountered is the one used. That actually worked, despite the change in spelling among [NAME(x)] and [NAME(y)] and [NAME]? That's news to me. But again, whatever the Yes, it actually works. rule is, it should be documented. For example, what would happen if there's white space in the name, e.g., [NAME(x, y)] or [ NAME] or [NAME ]? White space in the name is disallowed according to the current documentation. Documenting the behavior of multiple AC_DEFINE's would be great, but I don't think it is a valid objection to macros with arguments since multiple-AC_DEFINE behavior isn't documented even in the ordinary (non-argument) case as far as I can tell. But, in any case, it is easy to do: In the case of multiple AC_DEFINE statements for the same variable name (not including any parenthesized argument list), the last AC_DEFINE encountered is the one used. Also, ideally I'd like a complete patch: not just the documentation change, but the .m4 change. That is, I'd rather not go back to the old way of doing things, where users could AC_DEFINE any string and then get into real trouble. I'd rather have Autoconf check that the string being defined is in the subset of strings actually supported by Autoconf. This would be a fine patch, and would not be hard to implement, but it is an orthogonal issue. I'm not proposing going back to an old way of doing things. This is not a regression, just documentation of a reasonable and simple feature that autoconf has supported and relied upon internally for 6+ years. I don't quite understand why you want this documentation to be dependent on completely new features (checking of the AC_DEFINE variable for invalid characters, or documentation of multiple AC_DEFINE statements for the same variable) that apply equally to the old AC_DEFINE stuff. PS. Another question: is an empty argument list allowed? That wasn't clear to me either. An empty argument list is allowed only in the C99 standard (although it was widely supported previously). If a user wants to rely on C99 features, that is their call, but I wouldn't recommend it in config.h. The point is, we should refer to the C standard for the behavior of the argument list, which is defined by the C preprocessor and not by autoconf. Autoconf itself has nothing to do with the interpretation of the argument list, except for some very limited parsing to extract the variable name. This is not much different from how we treat the *value* of the AC_DEFINE, which again relies on the C standard for its interpretation (our only restriction is that we don't allow newlines). Steven
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
Steven G. Johnson [EMAIL PROTECTED] writes: why not say that the characters must be in [A-Za-z0-9_,()], and must form a valid cpp identifier and (optionally) a valid cpp argument list? That's a reasonable restriction, except (Ellipses are a C99 feature and it would not be a good idea to point users to them in a config.h file.) I don't see why not. One can easily use Autoconf to require C99, or to detect whether C99 is in use, and then (in a C99 context) it'd be reasonable to use ellipses. White space in the name is disallowed according to the current documentation. I assume this is talking about the documentation as altered by the 2006-12-15 change that disallowed parentheses in the name as well. So the idea is to rewrite that newly added restriction I'm not proposing going back to an old way of doing things. This is not a regression, just documentation of a reasonable and simple feature that autoconf has supported and relied upon internally for 6+ years. But there are at least two regressions here. First, the one reported by Andrey Simonenko in http://lists.gnu.org/archive/html/bug-autoconf/2006-12/msg00026.html, where AC_DEFINE([DEF(x)], [somevalue]) does not work in Autoconf 2.61 as it did in Autoconf 2.59. Second, the one I introduced in http://lists.gnu.org/archive/html/bug-autoconf/2006-12/msg00031.html, which explicitly generates a warning when you invoke AC_DEFINE([DEF(x)], [somevalue]). Any change to the documentation that defines AC_DEFINE to have its circa-2.59 meaning would need to be accompanied by a change to the code that fixes these two regressions. So far we don't yet have a specific patch proposed to do all these things (documentation + at least two code changes, I assume). I can easily generate a patch to fix the latter regression, but I don't know how the former regression came about. I don't quite understand why you want this documentation to be dependent on completely new features (checking of the AC_DEFINE variable for invalid characters, or documentation of multiple AC_DEFINE statements for the same variable) that apply equally to the old AC_DEFINE stuff. I'm trying to get the documentation fixed so that it's not so vague in this area -- clearly there are problems, since the behavior isn't well understood (at least by me). Since we're in the area, let's fix the obvious documentation problems in it. Admittedly this is not essential, but I'd rather not have to revisit the same issue later.
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
Steven G. Johnson [EMAIL PROTECTED] writes: (In fact, I believe I'm the one who originally patched autoconf to support macro arguments in AC_DEFINE.) That could well be, but it was never documented and it's not clear to me what the semantics would be. Are arbitrary characters allowed in the macro name? Surely not. What happens if we have AC_DEFINE([NAME(x)], ...) followed by AC_DEFINE([NAME(y)], ...) followed by AC_DEFINE([NAME], ...)? None of this stuff seems clear to me at all, with the old version. I'm open to having it be supported, but if so, these loose ends would need to be tied down, and the feature would need to be documented. (The hard part is probably the documentation)
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
Hello, On Tue, Dec 19, 2006 at 01:15:17PM +0200, Andrey Simonenko wrote: For example macro with arguments, depending on configure tests its value can be different. In config.h.in there can be #undef DEF (written by hands or generated by autoheader) and configure can change this line to #define DEF(x) somevalue, where somevalue can or can't use x. yes, but it seems that in practice it is nicer to encode the finding into several defined values (HAVE_FOO, HAVE_BROKEN_THAT, ...), and then define the parametrized macro in a separate hader file: #ifdef HAVE_FOO # define DEF(x) expression1 #elif HAVE_BROKEN_THAT # define DEF(x) #else # define DEF(x) something else #endif as you did when Paul decalred the feature as deprecated. And I think this is the right way. So I tend to believe that having macros without parameters in config.h is enough to transfer the information found out by configure. Regards, Stepan
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
* Stepan Kasal wrote on Tue, Dec 19, 2006 at 12:40:33PM CET: On Tue, Dec 19, 2006 at 01:15:17PM +0200, Andrey Simonenko wrote: For example macro with arguments, depending on configure tests its value can be different. In config.h.in there can be #undef DEF (written by hands or generated by autoheader) and configure can change this line to #define DEF(x) somevalue, where somevalue can or can't use x. yes, but it seems that in practice it is nicer to encode the finding into several defined values (HAVE_FOO, HAVE_BROKEN_THAT, ...), and then define the parametrized macro in a separate hader file: I disagree. Putting things in two separate files which belong together isn't nice and clean from an application point of view. It's coding around a restriction that Autoconf imposes upon the user (and has failed so far to document very explicitly). Cheers, Ralf
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
Hello, On Fri, Dec 15, 2006 at 10:35:37AM -0800, Paul Eggert wrote: Andrey Simonenko [EMAIL PROTECTED] writes: AC_DEFINE([DEF(x)], [somevalue]) Ouch! That's not supported, and I'm surprised you got it to work as well as it did. status.m4 contains a code which supports this, so until now I had no idea that this may be deprecated. I think this feature was available since the beginning of Autoconf. I understand that there is no real reason to use this feature, but OTOH, when we remove it we'll again hear cries that the Autotools people are never able to produce a backward compatible release. Shouldn't we rather maintain the feature? Have a nice day, Stepan
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
Hello Andrey, On Mon, Dec 18, 2006 at 03:40:08PM +0200, Andrey Simonenko wrote: AC_DEFINE([DEF(x)], [somevalue], [A macro to do a woo.]) As I understand this trick will not be supported in next versions of autoconf, so I reorganize logic of my .h files and now only simple identifiers (letters, digits and underline) are used [...] indeed, it seems that the defines without parameters are sufficient to transfer the findigs of configure. If you have a use case which shows that the (now deprecated) feature might be actually useful, we would be glad to hear about it. Thanks, Stepan
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
* Stepan Kasal wrote on Mon, Dec 18, 2006 at 07:31:59PM CET: I understand that there is no real reason to use this feature, but OTOH, when we remove it we'll again hear cries that the Autotools people are never able to produce a backward compatible release. Shouldn't we rather maintain the feature? Lazy me would like to vote yes, in case that counts anything, without actually doing the work right now. Cheers, Ralf
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
AC_DEFINE([DEF(x)], [somevalue]) Ouch! That's not supported, and I'm surprised you got it to work as well as it did. status.m4 contains a code which supports this, so until now I had no idea that this may be deprecated. I think this feature was available since the beginning of Autoconf. When you say this, do you mean AC_DEFINE([DEF(x)], [somevalue]), or do you mean merely putting something like this into config.h.in: #define DEF(x) somevalue and having 'configure' ignore it if DEF is not otherwise affected by substitutions? I understand that there is no real reason to use this feature, but OTOH, when we remove it we'll again hear cries that the Autotools people are never able to produce a backward compatible release. The old behavior was never documented, so I'm less sympathetic to this argument than I might otherwise be. Would you also support perverse configure.in files like this? They worked' in Autoconf 2.60 but not 2.61. (In 2.61 this test fails miserably, at autoconf time, with a mismatched m4 macro.) AC_INIT([TEST], [1], [somebody]) AC_DEFINE([DEF(x], [) x]) AC_CONFIG_HEADER([config.h]) AC_OUTPUT Shouldn't we rather maintain the feature? If it's easy to support the particular test that started this thread, please feel free.
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
[ This is part 1 of 2 of my answer to the report. ] Hello, On Thu, Dec 14, 2006 at 02:32:54PM +0200, Andrey Simonenko wrote: There is something different between 2.59 and 2.61 versions, indeed, you have discovered a regression, thank you. My reply comes in two mails; this one explains the solution to the problem reported, the other one analyses the regression. Why DEF is defined two times in config.h and why ABC is not defined two times? This question shows a misunderstanding: each of the line in the config.h.in is processed independently; it's just a pure coincidence when the earlier one is processed and the later one is passed untouched. In general, all #undef and #define directives are in danger that configure might modify them, so config.h.in should not contain any additional definitions. Please modify your templates this way: config.h.in: # undef ABC # undef DEF #include addendum.h -- addendum.h: #ifdef lint /* The undefs prevent warnings. */ # undef ABC # undef DEF # define ABC # define DEF(x) #endif /* lint */ -- addendum.h is safe; configure won't touch it. The template file is usually created by autoheader; to get a template like the above, use: -- configure.ac: AC_INIT([TEST], [1], [somebody]) dnl The third parameter describes the define. AC_DEFINE([ABC], [something], [Define ABC to a thing.]) AC_DEFINE([DEF(x)], [somevalue], [A macro to do a woo.]) AC_CONFIG_HEADERS([config.h]) AC_OUTPUT - Hope this helps, Stepan
AC_CONFIG_HEADERS regression (was: Re: autoconf 2.61: AC_DEFINE variable with parenthesis)
[ This is part 2 of 2 of my answer to the report. ] Hello, On Thu, Dec 14, 2006 at 02:32:54PM +0200, Andrey Simonenko reported the following regression: The temmplate: config.h.in: # define ABC # define DEF(x) results in: [...] autoconf-2.59: /* config.h. Generated by configure. */ # define ABC # define DEF(x) [...] autoconf-2.61: /* config.h. Generated from config.h.in by configure. */ # define ABC # define DEF(x) somevalue Further analysis: I tested the following lines: (The $ sign marks the end-of-line.) 1) #define ABC$ 2) #define ABC $ 3) #define ABC foo$ 4) #define DEF(x)$ 5) #define DEF(x) $ 6) #define DEF(x) foo$ This matrix shows which of the template lines are recognized: 2.59 2.61a 1) n n 2) n y 3) y y 4) n y 5) n y 6) n y (And I have verified that the situation is the same if the #define is replaced by # define.) So we observe a regression for templates 2), 4), 5), 6). I'm afraid that it was my changes to status.m4 which introduced the regression. Perhaps I intended the case 6) and a ``fix.'' But on a second thought, I think all these regressions are unwanted: Only the 3) is needed to support historical templates, the rest is just undefined behaviour. But since there seem to be no real reason to regress from 2.59, we should try to keep the historical behaviour, at least if it is easy to implement. What do you think? If there is a consensus that the regression should be fixed, I'll try to write a patch. Have a nice day, Stepan Kasal
Re: autoconf 2.61: AC_DEFINE variable with parenthesis
Andrey Simonenko [EMAIL PROTECTED] writes:
AC_DEFINE([DEF(x)], [somevalue])
Ouch! That's not supported, and I'm surprised you got it to work as
well as it did.
First things first: we have to clarify the documentation to make it
clearer that this isn't supposed to work, and add a warning in case
someone tries to do it anyway. I installed the following.
2006-12-15 Paul Eggert [EMAIL PROTECTED]
This change prompted by a problem report by Andrey Simonenko in
http://lists.gnu.org/archive/html/bug-autoconf/2006-12/msg00026.html.
* doc/autoconf.texi (Defining Symbols): AC_DEFINE works for
object-like macros only, in the traditional portable character
set.
* lib/autoconf/general.m4 (AC_DEFINE_TRACE_LITERAL):
Warn about attempts to define things that are not identifiers.
* lib/autoconf/fortran.m4 (_AC_FC_WRAPPERS): Rewrite to avoid
awful hack that AC_DEFINEd macro names containing parentheses.
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.1118
diff -u -r1.1118 autoconf.texi
--- doc/autoconf.texi 12 Dec 2006 17:53:13 - 1.1118
+++ doc/autoconf.texi 15 Dec 2006 18:24:47 -
@@ -8250,7 +8250,9 @@
@defmac AC_DEFINE (@var{variable}, @var{value}, @ovar{description})
@defmacx AC_DEFINE (@var{variable})
@acindex{DEFINE}
-Define the C preprocessor variable @var{variable} to @var{value} (verbatim).
+Define @var{variable} to @var{value} (verbatim), by defining a C
+object-like macro for @var{variable}. @var{variable} should be a C
+identifier that contains only letters, digits, and underscores.
@var{value} should not contain literal newlines, and if you are not
using @code{AC_CONFIG_HEADERS} it should not contain any @samp{#}
characters, as @command{make} tends to eat them. To use a shell variable,
Index: lib/autoconf/general.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/general.m4,v
retrieving revision 1.942
diff -u -r1.942 general.m4
--- lib/autoconf/general.m4 6 Dec 2006 21:17:48 - 1.942
+++ lib/autoconf/general.m4 15 Dec 2006 18:24:47 -
@@ -1951,7 +1951,10 @@
# ---
# Used by --trace to collect the list of AC_DEFINEd macros.
m4_define([AC_DEFINE_TRACE_LITERAL],
-[m4_pattern_allow([^$1$])])
+[m4_pattern_allow([^$1$])dnl
+m4_bmatch([$1], ^m4_defn([m4_re_word])$, [],
+ [m4_warn([syntax], [AC_DEFINE: not an identifier: $1])])dnl
+])# AC_DEFINE_TRACE_LITERAL
# AC_DEFINE_TRACE(CPP-SYMBOL)
Index: lib/autoconf/fortran.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/fortran.m4,v
retrieving revision 1.214
retrieving revision 1.216
diff -p -u -r1.214 -r1.216
--- lib/autoconf/fortran.m4 17 Nov 2006 21:04:54 - 1.214
+++ lib/autoconf/fortran.m4 15 Dec 2006 18:34:20 - 1.216
@@ -1033,40 +1033,82 @@ AC_LANG_POP(Fortran)dnl
# scheme used by the Fortran compiler.
AC_DEFUN([_AC_FC_WRAPPERS],
[_AC_FORTRAN_ASSERT()dnl
-AH_TEMPLATE(_AC_FC[_FUNC],
-[Define to a macro mangling the given C identifier (in lower and upper
- case), which must not contain underscores, for linking with Fortran.])dnl
-AH_TEMPLATE(_AC_FC[_FUNC_],
-[As ]_AC_FC[_FUNC, but for C identifiers containing underscores.])dnl
case $ac_cv_[]_AC_LANG_ABBREV[]_mangling in
- lower case, no underscore, no extra underscore)
- AC_DEFINE(_AC_FC[_FUNC(name,NAME)], [name])
- AC_DEFINE(_AC_FC[_FUNC_(name,NAME)], [name]) ;;
- lower case, no underscore, extra underscore)
- AC_DEFINE(_AC_FC[_FUNC(name,NAME)], [name])
- AC_DEFINE(_AC_FC[_FUNC_(name,NAME)], [name ## _]) ;;
- lower case, underscore, no extra underscore)
- AC_DEFINE(_AC_FC[_FUNC(name,NAME)], [name ## _])
- AC_DEFINE(_AC_FC[_FUNC_(name,NAME)], [name ## _]) ;;
- lower case, underscore, extra underscore)
- AC_DEFINE(_AC_FC[_FUNC(name,NAME)], [name ## _])
- AC_DEFINE(_AC_FC[_FUNC_(name,NAME)], [name ## __]) ;;
- upper case, no underscore, no extra underscore)
- AC_DEFINE(_AC_FC[_FUNC(name,NAME)], [NAME])
- AC_DEFINE(_AC_FC[_FUNC_(name,NAME)], [NAME]) ;;
- upper case, no underscore, extra underscore)
- AC_DEFINE(_AC_FC[_FUNC(name,NAME)], [NAME])
- AC_DEFINE(_AC_FC[_FUNC_(name,NAME)], [NAME ## _]) ;;
- upper case, underscore, no extra underscore)
- AC_DEFINE(_AC_FC[_FUNC(name,NAME)], [NAME ## _])
- AC_DEFINE(_AC_FC[_FUNC_(name,NAME)], [NAME ## _]) ;;
- upper case, underscore, extra underscore)
- AC_DEFINE(_AC_FC[_FUNC(name,NAME)], [NAME ## _])
- AC_DEFINE(_AC_FC[_FUNC_(name,NAME)], [NAME ## __]) ;;
+ 'lower case, no underscore, extra underscore' | \
+ 'lower case, underscore, no extra underscore' |
