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 -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
