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
