autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_DEFINE_UNQUOTED bug


From: Akim Demaille
Subject: Re: AC_DEFINE_UNQUOTED bug
Date: 05 Jun 2002 09:17:50 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]