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 ebb9@xxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
