Re: [pcre-dev] A problem with config.h.generic

On Fri, 7 Dec 2012, Philip Hazel wrote:

> (a) Stop massaging config.h.generic, but that would still suggest
> setting the value to 0.
>
> (b) Massage the comment in config.h.generic to say use #undef rather
> than setting to 0.
>
> (c) Modify all the tests in the code to test existence and value instead
> of just existence. This might be a bit messy.
>
> (d) Something else?
>

As for the config.h.generic (which I use) I'll be happy to follow any
documentation on its adjustments. Whereas currently I modify many of
the "#define VAR 1" into "#define VAR 0", I could change them into
"#undef VAR" if told to use that method. Hopefully the method for
specifying the boolean optionss in that file will be consistent.

I vote for (b) with the presumption that the PCRE code honors the
defined/undefined specifications. For example, when the file says:

/* Define to any value to enable the 16 bit PCRE library. */
/* #undef SUPPORT_PCRE16 */

then "any value" should not be used when a PCRE file contains a
"#if SUPPORT_PCRE16" because the "any value" someone puts there would
have to evaluate to boolean True. Defining "any value" of 0 could
be problematic if the PCRE code uses a mixture of "#ifdef" and "#if"
for the same option.

I'd also vote for (d) in that additional documentation or comments
in the file would be welcome. I can follow directions, and often
look for them soon after I've broken someting.

I could also live with (a) eliminating config.h.generic, but something
should take its place. Even if just the header output of the Cmake
method was provided, then I should be able to proceed as long as some
documentation was available somewhere as a guide. The existing
comments in config.h.generic are extremely helpful but perhaps having
them there is not required.

Unfortunately though, having or not having config.h.generic may be
more important to new users than it is to people already on this list.
It's where I started when first trying to build a PCRE library. It
seemed unlikely that other generic build methods would satisfy some
particular needs (such as memory management) and in the end that was
the right thing to do.


Graycode