Re: If-statement influencing syntax/content in config.h? Naming convention for preprocessor variables.

[Lukas Kaser]

Hi Eric,

thanks for your detailed answer!

Autoconfs behaviour makes complete sense to me now. Really happy with it.

I would like to ensure if you mean with " If you follow recommended
practice of not installing config.h" not to distribute config.h.  Am I
right? I didn't implement the (any) make install till now, but I think
no header file of the project I'm helping to maintain needs to be make
installed, e.g. to /usr/include.

Best,
Lukas

2010/4/30 Eric Blake <address@hidden>:
> On 04/30/2010 11:32 AM, Lukas Kaser wrote:
> [slightly reorganized, to make my reply flow better]
>
>>
>> => config.h
>> /* Whether compiled with NEWRENDERER */
>> /* #undef COMPILE_NEWRENDERER_RENDERER */ dnl ############# <-- here
>
> This is the default action if the configure script never reaches an
> AC_DEFINE* for that variable.
>
>> [configure.ac]
>> if test x$build_newrenderer = xtrue ; then
>>         AC_DEFINE_UNQUOTED([COMPILE_NEWRENDERER_RENDERER],
>> [${build_newrenderer}], [Whether compiled with NEWRENDERER])
>> fi
>
> In this case, if $build_newrenderer is not true, then the AC_DEFINE is
> unreached, explaining why config.h ends up with the default behavior.
>
>>
>> dnl if test x$build_newrenderer = xtrue ; then
>>         AC_DEFINE_UNQUOTED([COMPILE_NEWRENDERER_RENDERER],
>> [${build_newrenderer}], [Whether compiled with NEWRENDERER])
>> dnl fi
>
> Here, the AC_DEFINE is reached unconditionally, which explains why:
>
>>
>> => config.h
>> /* Whether compiled with NEWRENDERER */
>> #define COMPILE_NEWRENDERER_RENDERER false  dnl ############# <-- here
>
> you get an unconditional substitution, whether $build_newrenderer was
> true or false.
>
>> Second I would like to know how the naming conventions are. Does most
>> of the people follow the naming-convention "HAVE_VAR_NAME" for
>> config.h?.
>
> As long as the name doesn't conflict with other names defined
> automatically by autoconf, and reads well in your usage contexts, you
> are probably okay with that name.  If you follow recommended practice of
> not installing config.h, then only your package has to worry about the
> name you chose, even if you don't name it in the HAVE_* namespace.
>
> --
> Eric Blake   address@hidden    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
>
>