Re: AC_DEFINE_UNQUOTED bug

[Stefan Seefeld]

Akim Demaille wrote:
> | 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.

not in the docs I read. Please show me where it is discouraged in:

http://www.gnu.org/manual/autoconf/html_mono/autoconf.html

On the contrary !

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

talk about clarity. But anyways, I now understand why it couldn't work.

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

right, I see.

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

If it was as easy as this. There *are* things that need to be exposed 
through the API, not everything can be hidden. But well, I'v found a way 
around the trouble.

Thanks,
                Stefan