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
