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

Startseite
Nachricht löschen
Autor: Robert Roessler
Datum:  
To: Philip Hazel
CC: pcre-dev
Betreff: Re: [pcre-dev] Kudos on PCRE 7.2...
Philip Hazel wrote:
> On Tue, 28 Aug 2007, Robert Roessler wrote:
>
>>> There is a 7.3 release coming out, possibly even today. It has already been
>>> changed back. The release candidate has been around for nearly a week since
>>> the last comment, so I think it is time to go public.
>> I would *really* have liked to see this before it was released... but the
>> pcre.org site shows no "betas" or "RCs". :(
>
> The pcre.org site is run by a PCRE fan. All my stuff is on
>
> ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/


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". :|

>> Yes, the instance I mention above was switched back to the "" form - but the
>> former SINGLE #include "config.h" in pcre_internal.h has now apparently been
>> replaced by 22 #include <config.h> uses across the whole project.
>
> If you look at the mailing list archives you'll see discussion about
> this. I questioned it, but Daniel argued that it was the "standard" and
> recommended way to go, to ensure that #include config.h appeared *at
> the very start* of every code module, before anything else that might be
> relying on what was set in the config. We also had the < vs "
> discussion; I must confess to not being totally convinced, and also I
> guess it's my fault for not noticing the new #includes use < rather than
> ".
>
> I suspect I can't win on this, though. Perhaps Robert and Daniel can
> discuss on the list and come to some conclusion. I imagine it's all to
> do with auto vs manual building, and also building in other (non-source)
> directories comes into it as well. This is an area I know little about.


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)... 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?

Yes, I *can* still build it with Visual Studio 2005 (which does happen
to include a serious and high-quality C/C++ compiler), but the
underlying model seems to be going more and more to requiring/assuming
you are *of course* using auto-this and auto-that... and the answers I
received from Bob and Daniel reflect that (but I am still appreciative
of the time it took to give them).

It's not like we are trying to build an operating system (or a Mozilla
FireFox) here... PCRE has historically been a clean, contained
*library*, without exotic build requirements (or the mindset that goes
with them), and it somehow managed to become an influential building
block in lots of software nonetheless... :)

OK, semi-rant-mode OFF (well, mostly).

>> Each of the newly added '#include <config.h>' is "protected" by a '#ifdef
>> HAVE_CONFIG_H' - which presumably should be '#ifndef'?
>
> I don't think so... Daniel? Is this a valid comment? Everything works
> fine on Unix, and others seem to have used the RCs on Windows.
>
>> Not to mention the '# ifdef...' inside the '#ifndef DFTABLES' in
>> pcre_maketables.c...


This was apparently my bad - I mistook this for a widely used idiom that
is employed to *prevent* header files from being multiply included...
although, again, the way it is apparently supposed to work requires me
to define HAVE_CONFIG_H just to get config.h brought in?

In the new 20x places instead of one? And this is an improvement
(rhetorical question)? At least it would be nice if this was mentioned
as something that one must do, if all you are doing is a simple sequence
of compiles followed by a librarian invocation.

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?

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... ;)

"A concerned long-time PCRE user"

Robert Roessler
robertr@rftp.com
http://www.rftp.com