A loud resounding "Amen" to Guenter from the Windows balcony.
I have reservations however.
1. I have a patch that let's me build trunk with the PCRE 5.0 from 2.2,
but I do not want to stay at PCRE 5.0 cause you have to have something
newer to link mod_security 2.5.12+ against, so I have to build something
newer regardless (not that any 3rd party module even works in 2.3.x at
the moment).
2. I have no problems building PCRE 8 on Windows w/ CMake and dropping
the 4 files in srclib/pcre. The annoyance is makefile.win wanting to
copy the non-existing pcre.pdb and barfing there. Another patch ;-)
3. I have not been able to get pcre 8 (current 8.10) to build in tree
like pcre 5 on 2.3.x, in 2.2.x yes. The static lib seems to not export
some needed symbols (pcre_free comes to mind as one). I have not tried
building in tree as DLL however.
While not ignoring Paul's comments included with his NO vote, as I see
it, there are three different build systems included in the tarballs,
Windows, Netware and one for most flavors of Unix. We get the code for
mod_suexec which in not built on Windows and just sits there dormant,
why could PCRE not be included (for Windows and Netware and OS/2 and ?)
and just simply not be included in the makefiles and sit there dormant
in the different flavors of Unix as mod_suexec does on Windows/Netware?
So if I could vote, I'd vote +0.5 till I knew what version you were
planning on including and it would only go to a full 1 if pcre was not
built on Unixs' and was newer than 6.5 (the mod_security minimum IIRC).
Regards,
Gregg
Guenter Knauf wrote:
Hi all,
Am 24.08.2010 18:42, schrieb Jim Jagielski:
The pre-release test tarballs for httpd-2.3.8 (alpha) are
available for download, test and fun:
http://httpd.apache.org/dev/dist/
Will call for a release vote in a coupla days...
I know that this topic was already up here, but nevertheless I think we
should re-think about including PCRE again.
Other than openssl or zlib PCRE is a mandatory dependency like APR/APU,
and I see no benefit in dropping it from our dependencies deliveries
other than making tarballs smaller, and that is nowadays certainly not
an issue anymore.
We want Apache to build form source on at many platforms as possible -
sure the main target is Linux / Unix, but we have a couple of other
platforms where PCRE is not installed by default, that are at least
Win32, NetWare, most likely OS/2, and probably a couple of others too.
I tried to build 2.3.7 already for NetWare and Win32, and while NetWare
went fine only because I have an (self) adapted makefile (from previous
times when we shipped PCRE), the Win32 stuff is horrible: there comes
some suggestion up that I should build PCRE with CMake with xxx option;
1st I have to download CMake and depend on another build tool (ok, not
that big issue), but whats even more worse is that the CMake build
failed for me, and thats really bad - you cant just go and build httpd
as you do on Linux, no! Your build process is always interupted, and
probably as in my case finally broken at all.
Hey, friends, we do much better with 2.2.x where we ship PCRE: we have
our own makefile, and the build goes through in one go without need for
other tools like CMake - just the compiler and probably a platform PDK
are enough (and thats how it shoud be).
Therefore I want to start a vote here again where we vote for including
PCRE again with the dependencies - just as we (now) do with APR/APU;
and everyone who votes against should give some good reasons what speaks
against -- the fact that every Linux comes with PCRE is certainly no
good reason - it only leads finally to the fact that we might end up
with 50 builds of httpd 2.after-2.x with different PCE versions which
makes then nice bug hunting, and we cant even tell someone who faces a
prob to 'use our shipping PCRE which is known to be good'.
Here we go:
[ ] YES - include recent PCRE again with dependencies (means we
create a PCRE repo in svn, check in a recent version, and add
platform-dependent makefiles which are fully integrated into
main build process).
[ ] NO - dont include PCRE (as currently) because of reason: ...
thanks, Gün.
