On Sun, 16 Sep 2018, Ze'ev Atlas via Pcre-dev wrote: > This is NOT a bug per se, but my C compiler does not really recognize this > construct
> <snip> What you have quoted is from pcre2.h.in, which gets transformed by "configure" or CMake into pcre2.h. > my compiler will recognize that PCRE2_HAVE_STDINT_H is defined but I > do not know about any way to set the value to zero or one. Remember > that I do not have any MAKE, CMAKE etc. on the classic z/OS. How did you manage with the other settings in the past? There have always been #define PCRE2_MAJOR @PCRE2_MAJOR@ #define PCRE2_MINOR @PCRE2_MINOR@ #define PCRE2_PRERELEASE @PCRE2_PRERELEASE@ #define PCRE2_DATE @PCRE2_DATE@ at the start of pcre2.h.in. > I could set macros and compile options outside the source code (the > equivalent of Dmacroname or Umacroname and compiler options). But the > construct > #define macroname @externalvalue@is not part of it > I could manually remove these lines from pcre2.h and set the values > externally but there should be a better way. The IBM C compiler does adhere > with the latest concept so there should be an equivalent.In short, when you > accommodated systems without stdint.h or inttypes.h (I have both,) you have > created a problem for systems without CMake! But this is not a new problem, as I've pointed out above. However, I can see that previously using pcre2.h.generic would have worked, but now it does contain #define PCRE2_HAVE_STDINT_H 1 #define PCRE2_HAVE_INTTYPES_H 1 that is, it assumes the presence of those headers. This change was made at a user's request in order to make life easier for ancient or non-standard environments. Standard environments should have stdint.h, so perhaps just using pcre2.h.generic is the answer. Philip -- Philip Hazel -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
