| In a little test I use three versions of AC_DEFINE_UNQUOTED:
|
| AC_DEFINE_UNQUOTED($ac_tr_decl, 1, [yadayada])
This is midly discouraged in the doc.
| AC_DEFINE_UNQUOTED(foobar1, 1, [yadayada])
| AC_DEFINE_UNQUOTED(foobar2, $ac_tr_decl, [yadayada])
|
|
| in the first case the variable name itself is a variable,
| in the second there is no variable (so I could in fact use
| AC_DEFINE), in the third the value is a variable.
|
| Only the last two result in an entry in the header template
| generated from autoheader (I'm using autoconf 2.53, by the way).
It cannot guess runtime values, hence the docs discourages it.
| The autoconf docs clearly state that all three forms are valid.
In order to do its job, @command{autoheader} needs you to
document all of the symbols that you might use; i.e., there
must be at least one @code{AC_DEFINE} or one
@code{AC_DEFINE_UNQUOTED} using its third argument for each
symbol (@pxref{Defining Symbols}). An additional constraint
is that the first argument of @code{AC_DEFINE} must be a
literal. Note that all symbols defined by Autoconf's built-in
tests are already documented properly; you only need to
document those that you define yourself.
| Where is the error ?
It is not technically impossible to pass a var as 1st arg to
AC_DEFINE: it's job will be done. It's technically impossible to
expect autoheader to understand this.
| PS: oh, and I had to realize that I can't use '#undef' in
| AH_BOTTOM to work around the exposure of the PACKAGE variables
| as I reported earlier. This makes the whole AH_TOP and AH_BOTTOM
| business redundent,
Absolutely.
| as I do need to define my own wrapper header
| anyways that undefs the macros I don't want to expose, i.e. assuming
| I generate 'acconfig.hh.in' from configure.ac containing
| '#undef PACKAGE_NAME' as generated with autoheader, I have to write
| my own header 'config.hh' like this:
As already reported, it is wrong to expose config.h to other
packages. It's private.
