[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: If-statement influencing syntax/content in config.h? Naming convent
From: |
Lukas Kaser |
Subject: |
Re: If-statement influencing syntax/content in config.h? Naming convention for preprocessor variables. |
Date: |
Mon, 3 May 2010 19:02:33 +0200 |
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
>
>
- Re: If-statement influencing syntax/content in config.h? Naming convention for preprocessor variables.,
Lukas Kaser <=