Brian Dessent wrote:
> though. The build infrastructure for PHP doesn't support Cygwin and
> it's a real nightmare to try to work with.
I just want to add a couple of clarifications to that statement, as I'm
sure somebody will dig this up in the archives in 5 years and somehow
try to use it to mean something I didn't intend.
A. I was working with php 4.x and apache 1.x at the time. Things might
have improved in 5.x and I'm sure things have improved in 2.x,
build-system wise.
B. I was explicitly working with the requirement that all PHP modules be
shared and not static, since this allows for much greater user
flexibility, e.g. "I don't want to also have to download and install
Postgres libraries and have the Postgres PHP modules resident in memory
even though I use MySQL and don't use Postgres at all." If you can
settle for a static PHP binary then things become a lot simpler and it's
not too hard to get a Cygwin PHP running. But then you're forced to
live with the module choices of the person that built the package.
C. The motivation to do this is somewhat sapped by the fact that native
Win32 binaries (and even fancy automated GUI one-click installers) have
existed for the Apache/PHP/MySQL stack for quite a while, so the Windows
user can simply use these if they really need to work with PHP. And I'm
positive that these native versions are much faster than their Cygwin
counterparts. So the only remaining reason for wanting a Cygwin port of
the stack is for people that need to replicate a unix environment as
closely as possibe. But even then, the win32 native ones can come
pretty close in most respects.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/