Re: Question: Configuration Header Templates

[Eric Blake]

According to Jeffrey Walton on 2/15/2010 2:32 PM:
>>> After bootstrap/configure, this produces (in config.h):
>>> /* Force the usage of the 64 bits bignum ... */
>>> /* #undef PDF_FORCE_BIGNUMS */
>>
>> That is typical behavior for when a feature was not selected.
> Since the #undef is commented, it leads me to believe that BIGNUMS are
> in use and one should uncomment to use a built-in 64 bit type. Put
> another way, why would one need to #undef something that is not in
> use?

The way that config.h templates work is that everything is listed as
commented-out #undef (why? because some symbols, like _GNU_SOURCE, would
interact badly with system headers if explicitly #undef'd).  Then,
configure determines which templates to uncomment, and only those
templates are turned into uncommented #defines.

If config.h still contains a commented line, then configure did NOT select
that symbol for definition, which means that feature was NOT requested
during configure.  In your case, BIGNUMS are not requested, and you should
not assume 64-bit bignums.

> If BIGNUMS are not being used, I would expect that the comment would
> be '#define PDF_FORCE_BIGNUMS' or  '#define PDF_FORCE_BIGNUMS 1'. This
> makes sense to me - one should define something a PP symbol if they
> want to use the feature.

That's atypical logic.  Generally, you want a macro to be undefined (or
else explicitly defined to 0) if a feature is not in use, and explicitly
defined to 1 if the feature is in use.  Thus, you want PDF_FORCE_BIGNUMS
to be 1 if BIGNUMS _are_ being used.

> 
>> Also, are you sure you are testing the use of
>> './configure --enable-bignum-forcing'?
> I'm not sure about this (I just joined the project).

You may want to ask more about this specific configuration on your project
then; the autoconf list only gives generic advice about how to write
configure scripts, and not details about how the particular script of your
project will behave.

> Personally, when
> I jump between BIGNUMS or built-ins for testing, I either '#define
> PDF_FORCE_BIGNUMS' or I comment it out (and then re-make). I don't
> re-configure since the define is available in config.h. I can't speak
> for others, or how the testing framework might use the switch.

Yes, manual editing of config.h can be faster than re-running configure,
which is why autoheader recommends that each #define in config.h be given
a reasonable comment about what the macro means.  But most people will
rely on configure, not manual editing, so keep that in mind before
distributing your package.

> 
> Also, if it matters: In the code, the conditional compilation occurs
> on PDF_USE_BIGNUMS. The PP statements look similar to:
> #if defined(x) || defined(y) || !defined( PDF_FORCE_BIGNUMS)
> #  define USE_BUILTIN_64
> #endif

More parenthesis than necessary, but that's a style thing.  OK, now your
earlier statements make a bit more sense - it looks like your project is
using PDF_FORCE_BIGNUMS in a negative sense - if undefined, then rely on
native 64-bit types without extra effort by defining USE_BUILTIN_64; if
defined, then native 64-bit types are insufficient, so don't use them.
Still awkward, compared to most autoconf macros used for positive sense
instead of negative sense, but not necessarily wrong as long as it is
well-documented why the negative sense was chosen.

-- 
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden

signature.asc
Description: OpenPGP digital signature