Thanks
I have created a mini configure in my conversion scripts that deal with the pcre2.h, drawing information from the ac file. I will extend similar logic for the config.h.
I will check where are all those macros used and see whether i can recommend getting rid of any
Zeev Atlas
Sent from Yahoo Mail on Android
From:"ph10@???" <ph10@???>
Date:Thu, Sep 24, 2015 at 2:09 PM
Subject:Re: config.h vs. pcre2.h - version number
On Thu, 24 Sep 2015, Ze'ev Atlas wrote:
> Working on a first release of PCRE2 for z/OS, I've downloaded build
> 371 (no point on downloading the old original) and discovered that
> while pcre2.h (.n, .generic, whatever) is already geared towards 10.21
> -RC1, the config.h.generic is still stuck with 10.20. I have a few
> questions:
> 1. Why, at all do we need this information in two separate places.
> Shouldn't the information in pcre2.h suffice?
In the Linux/Unix "configure; make; make install" world, config.h is
generated from config.h.in when "configure" is run, and there is a
similar mechanism that CMake uses.
As it says in NON-AUTOTOOLS-BUILD:
Versions of src/config.h and src/pcre2.h are distributed in the PCRE2
tarballs under the names src/config.h.generic and src/pcre2.h.generic.
These are provided for those who build PCRE2 without using "configure"
or CMake. If you use "configure" or CMake, the .generic versions are
not used.
In fact, the .generic version is only normally generated when a release
is created (that's why it still says 10.20).
So actually, the "real" information is in config.h.in and the other
files are generated from it.
> 2. In config.h itself, I have the information in 3 places:
> /* Define to the full name and version of this package. */
> #define PACKAGE_STRING "PCRE2 10.20"
> /* Define to the version of this package. */
#define PACKAGE_VERSION "10.20"
> /* Version number of package */
#define VERSION "10.20"
> My question is, while I may see the the difference between the first two, why do I need the third, isn't it a relic from past version?
I don't know why there are all those defines. It's what "configure" generated.
I only ever define the version in one place, a file called configure.ac,
which is the driving file for "configure". Maybe there's a historical
reason for having the three different #defines. In my version of
config.h I see 10.21 for all three. However, the code of pcre2 does not
use any of these macros.
Hmm. I now see that I have all the config.h files set up to be ignored
by svn because they are generated files (config.h.in is generated by
automake). There shouldn't even be copies in the repository. I guess
that's a mistake, because it has confused you! I have now arranged for
config.h and config.h.in to be updated in the repository.
> 3. If ultimately, we need the information in both headers (see question #1), which should I choose (i.e. should I adjust the config.h or pcre2.h?)
Like config.h, pcre2.h is generated from pcre2.h.in, though the only
difference between them is the version numbers at the front. pcre2.h.in
contains
#define PCRE2_MAJOR @PCRE2_MAJOR@
#define PCRE2_MINOR @PCRE2_MINOR@
#define PCRE2_PRERELEASE @PCRE2_PRERELEASE@
#define PCRE2_DATE @PCRE2_DATE@
These lines get substituted when pcre2.h is generated. So I guess you
could most conveniently work from pcre2.h. For config.h, I think you are
best using config.h.in because it will be fairly stable, whereas
config.h will be whatever configuration I happen to have configured
today. Or maybe I should try to update config.h.generic more often. I
have just updated it.
Bottom line: the repository is somewhat of a "work in progress" and only
when a release is packaged up are all the files fully updated.
Philip
--
Philip Hazel
