Re: [pcre-dev] Kudos on PCRE 7.2...

On Wed, 29 Aug 2007, Robert Roessler wrote:

> Silly me - I used to only go to your FTP server, but then I saw the Web site
> start getting more regular updates reflecting current activity - and made the
> incorrect assumption that it was now "the place". :|

Well, it might be in due course - I guess you can say we are still in
some kind of transition.

> Mr Philip (and Bob and Daniel), I am unhappy to see the PCRE project head in
> the direction of more complexity in the build environment for little (if any)
> gain (obviously MY opinion)...

It does seem to have gained for the automatic build folks, both on Unix
and Windows. The changes were not just made "for the hell of it" but
because people had had problems.

> but seriously, even if there is no concern for Windows at all (which
> doesn't seem to quite be the case), switching away from a structure
> which could be trivially built with only a make and a compiler (or an
> IDE handling both functions) doesn't make a whole lot of sense from an
> engineering standpoint, does it?

I tried to keep such folks in mind (hence the distribution of the
.generic files), but obviously got it a bit wrong. I have to say that I
think you are in a minority, but it is a minority that I would like to
cater for if at all possible.

> the way it is apparently supposed to work requires me to define
> HAVE_CONFIG_H just to get config.h brought in?

I clearly wasn't paying attention to this change. And yes, of course it
should be documented. That's my bad.

> And then there is the changing of other symbols like PCREPOSIX_STATIC in 7.2
> becoming PCRE_STATIC in 7.3? Things like this make life harder for the
> consumers of PCRE, and what did it buy?

It was part of a bug fix. The POSIX functions were screwed up in Windows
builds - there were complaints. It's all to do with the really
complicated and messy requirements that are required for Windows DLL
libraries. Stuff like extern __declspec(dllimport) which is not Standard
C. At least on Unix the complication of shared libraries is all in the
external building stuff - the code can be pure C.

I was even forced to learn a bit about this Windows messiness in order
to get it right for pcre.h (for an earlier release), but I forgot about
the POSIX interface, which is why it had to be fixed in this release.

> I know it is quite unlikely, but *maybe* some of the changes that went into
> the [unfortunate] 7.3 release could be carefully reviewed - and the ones that
> aren't bugfixes reversed? I would be happy to do the edits... ;)

Personally, I would be happy to change <config.h> to "config.h". The use
of <> has always seemed wrong to me. I am not sure if there is anything
else that can be done that won't break the "automatic" build methods -
and (unfortunately for you) I think the majority of PCRE builders do use
them.

> "A concerned long-time PCRE user"

My interest all along has been in the *code* rather than how you build
it. Early releases just built a static .a file; it was the growing
popularity of PCRE that caused pressure for it to be built as a shared
library - enter the nightmare world of libtool - and that's where the
complication started.

Finally, I have to say that the new scheme has also made things better
for me. For example, using "make distcheck" now means that I can't make
a distribution that is missing a vital file. And the release number is
handled automatically. Little things, but the less I have to remember,
the smaller the chance of getting it wrong.

Philip

--
Philip Hazel, University of Cambridge Computing Service.