Re: Musings on PHP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max Bowsher wrote: > I personally have no need for PHP, but I know it's a very widely > used piece of software. > > After John Morrison's recent mention of PHP in passing, I decided > to do a quick estimate of how difficult getting PHP working on > Cygwin would be. To cut a long story short, I got a bit carried > away, and now have a functional apache2 php5 module. In case you do decide to package it, please enable also FastCGI, it can be very handy with lighttpd =) And, if you don't see any reason not to, please do include - --enable-zend-multibyte option: sadly still undocumented[1], but actually works very well (I use it in production system both Windows and FreeBSD since a long time), has the nice property to let PHP understand automatically the format of UTF-x .php files and thus avoid many localitazion problems. [1] except here: http://bugs.php.net/bug.php?id=22108 > PHP definitely needs its postgresql support available to be useful > most non-trivial application. If I want to avoid creating a hard > dependency on the postgresql package, the PHP pgsql extension needs > to be built as a shared library. I'd go down this road, but for the main reason that I do not need pgsql, and if it is so much more difficult, if I was the mantainer I'd probably go for the hard dependency and use the good old excuse that disk space is cheap ;-) Lapo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJDvmFEAAoJELBiMTth2oCDPOkP/3cNOmWpB/XdZ2GAvoMeWSk/ fQ6SXDZznzHmKScjoalBIyPB6CkYW2v9txNdboJ18cgW2Bt0ppa55ESERGaa4r4F b6OeQc6oeZt6+RCXYhXCZGTF3/eTwUhrAQkpeYgznlOMmEDtjP4Jg42CY7pg04MH HnMba4f95iJg7OBP2f3yLeRyiBO0ekEKmoGqTDzBOyI87IKlO5ZK7uZxzM5/DAql GgpVvjhqwkTEPYzVGgfTv6UEU86R8xIVYRrPOXwQ6nRvMRpILb4dDGA+j4/QZ9EI TUyD7gX8BNOstaDVlw5/cgWIGtPPfl1NyaX1XJeSjMfi1r/dPANg1CV+VfSq4vlr i6aidk/vKleNW4d/JeCH5qnTeOrn1fJ1PIUUqPh/RLZ/oqc4vV4/BU4jvpZtgLUb rZixax5Eh+znhUlkns35YMCGk2Ko/aeFTw0am1eYBeBS8PidtU/tbOeO0dXET22m d3YYkBXn4UmEtr2x7DI9mggsMQ4pZ3VYoOCYcl7QMFo7EdTxsvdBA2YcHRyxAOPb hNJ1N+gi3l47JX/QGJtXKLlFmaN++4wBgHdjuv7/1dc7eGC1uR7ecYj2WviFWKmW pzoH2EOjNbJaw4BTYzrRA8FLUXw/+FsRn+RRhXU+0lV80s/ePJItvpKYoKd11cd7 t20fzn2PgqxTTFZnxqk9 =GgJo -END PGP SIGNATURE-
Re: Musings on PHP
Robert Richter wrote: I didn't really intend to package PHP, but having got this far, I sort of feel I ought to. Which brings me to two major issues concerning any potential Cygwin PHP package: 1) Two apache versions. I've no interest in Apache 1.3.x. Can I just package PHP for 2.x, and worry about 1.3.x only if a potential maintainer steps forward? I already got a PHP 4.3.10 version running on Apache 1.3.x and plan to add PHP to the Apache 1.3.x release. I am not sure if this is the best solution but maintenance effort decreases. In the same package? That doesn't seem like a good idea. That is likely to confuse users, and will lead to unnecessarily large updates when one of Apache/PHP needs to be updated, but the other does not. On the other side a separate package could be included also by Apache2 and package conficts would be avoided. I don't understand how this will avoid conflicts? Although I have never explicitly tried, at the moment, it should be possible to install and run both apache1 and apache2 simultaneously. If there are to be two independent PHP packages, we need to avoid file name conflicts between them, just like no files in the apache & apache2 packages share names. Max.
Re: Musings on PHP
> I didn't really intend to package PHP, but having got this far, I sort of > feel I ought to. > Which brings me to two major issues concerning any potential Cygwin PHP > package: > > 1) Two apache versions. > > I've no interest in Apache 1.3.x. Can I just package PHP for 2.x, and worry > about 1.3.x only if a potential maintainer steps forward? > I already got a PHP 4.3.10 version running on Apache 1.3.x and plan to add PHP to the Apache 1.3.x release. I am not sure if this is the best solution but maintenance effort decreases. On the other side a separate package could be included also by Apache2 and package conficts would be avoided.
Re: Musings on PHP
On Sun, September 18, 2005 10:05 pm, Max Bowsher wrote: > I personally have no need for PHP, but I know it's a very widely used > piece of software. > > After John Morrison's recent mention of PHP in passing, I decided to do a > quick estimate of how difficult getting PHP working on Cygwin would be. To > cut a long story short, I got a bit carried away, and now have a > functional apache2 php5 module. Wow! Thanks Max - I really didn't expect you to go to this much trouble! I can't help with the questions you asked, but I just wanted you to know that I'm appreciative of all the effort you've put in. J.
Re: Musings on PHP
Max Bowsher wrote: 2) Shared library headaches. PHP definitely needs its postgresql support available to be useful most non-trivial application. If I want to avoid creating a hard dependency on the postgresql package, the PHP pgsql extension needs to be built as a shared library. But to make that work for both the php command line executable and the apache module, I'd have to significantly tweak the PHP build process, introducing an extra library to contain the core PHP engine, instead of just linking the component object files into both the php exe and the apache module. So... is it worth messing with the build system to this extent, or should I just go the easy route, and have a hard dependency on postgresql's cygpq.dll? Basically it is much better to have a shared core used by both the module and the CLI. This reduces the size. My last build was pretty easy. With some minor fixes to get several modules compiled, the major change to get a shared core was in the Makefile: changing some lines *after* it was generated. s.th. like the attached patch should do it (this was from a build without the Apache module). Gerrit -- =^..^= --- Makefile~ 2005-07-04 00:11:07.883892800 +0200 +++ Makefile2005-07-04 01:38:40.427721600 +0200 @@ -35,7 +35,7 @@ shared_objects_gmp = ext/gmp/gmp.lo GMP_SHARED_LIBADD = -lgmp shared_objects_iconv = ext/iconv/iconv.lo -ICONV_SHARED_LIBADD = +ICONV_SHARED_LIBADD = -liconv shared_objects_mbstring = ext/mbstring/mbstring.lo ext/mbstring/php_unicode.lo ext/mbstring/mb_gpc.lo ext/mbstring/php_mbregex.lo ext/mbstring/oniguruma/regcomp.lo ext/mbstring/oniguruma/regerror.lo ext/mbstring/oniguruma/regexec.lo ext/mbstring/oniguruma/reggnu.lo ext/mbstring/oniguruma/regparse.lo ext/mbstring/oniguruma/regenc.lo ext/mbstring/oniguruma/regext.lo ext/mbstring/oniguruma/regsyntax.lo ext/mbstring/oniguruma/regtrav.lo ext/mbstring/oniguruma/regversion.lo ext/mbstring/oniguruma/st.lo ext/mbstring/oniguruma/enc/unicode.lo ext/mbstring/oniguruma/enc/ascii.lo ext/mbstring/oniguruma/enc/utf8.lo ext/mbstring/oniguruma/enc/euc_jp.lo ext/mbstring/oniguruma/enc/euc_tw.lo ext/mbstring/oniguruma/enc/euc_kr.lo ext/mbstring/oniguruma/enc/sjis.lo ext/mbstring/oniguruma/enc/iso8859_1.lo ext/mbstring/oniguruma/enc/iso8859_2.lo ext/mbstring/oniguruma/enc/iso8859_3.lo ext/mbstring/oniguruma/enc/iso8859_4.lo ext/mbstring/oniguruma/enc/iso8859_5.lo ext/mbstring/oniguruma/enc/iso8859_6.lo ext/mbstring/oniguruma/enc/iso8859_7.lo ext/mbstring/oniguruma/enc/iso8859_8.lo ext/mbstring/oniguruma/enc/iso8859_9.lo ext/mbstring/oniguruma/enc/iso8859_10.lo ext/mbstring/oniguruma/enc/iso8859_11.lo ext/mbstring/oniguruma/enc/iso8859_13.lo ext/mbstring/oniguruma/enc/iso8859_14.lo ext/mbstring/oniguruma/enc/iso8859_15.lo ext/mbstring/oniguruma/enc/iso8859_16.lo ext/mbstring/oniguruma/enc/koi8.lo ext/mbstring/oniguruma/enc/koi8_r.lo ext/mbstring/oniguruma/enc/big5.lo ext/mbstring/oniguruma/enc/utf16_be.lo ext/mbstring/oniguruma/enc/utf16_le.lo ext/mbstring/oniguruma/enc/utf32_be.lo ext/mbstring/oniguruma/enc/utf32_le.lo ext/mbstring/libmbfl/filters/html_entities.lo ext/mbstring/libmbfl/filters/mbfilter_7bit.lo ext/mbstring/libmbfl/filters/mbfilter_ascii.lo ext/mbstring/libmbfl/filters/mbfilter_base64.lo ext/mbstring/libmbfl/filters/mbfilter_big5.lo ext/mbstring/libmbfl/filters/mbfilter_byte2.lo ext/mbstring/libmbfl/filters/mbfilter_byte4.lo ext/mbstring/libmbfl/filters/mbfilter_cp1251.lo ext/mbstring/libmbfl/filters/mbfilter_cp1252.lo ext/mbstring/libmbfl/filters/mbfilter_cp866.lo ext/mbstring/libmbfl/filters/mbfilter_cp932.lo ext/mbstring/libmbfl/filters/mbfilter_cp936.lo ext/mbstring/libmbfl/filters/mbfilter_euc_cn.lo ext/mbstring/libmbfl/filters/mbfilter_euc_jp.lo ext/mbstring/libmbfl/filters/mbfilter_euc_jp_win.lo ext/mbstring/libmbfl/filters/mbfilter_euc_kr.lo ext/mbstring/libmbfl/filters/mbfilter_euc_tw.lo ext/mbstring/libmbfl/filters/mbfilter_htmlent.lo ext/mbstring/libmbfl/filters/mbfilter_hz.lo ext/mbstring/libmbfl/filters/mbfilter_iso2022_kr.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_1.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_10.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_13.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_14.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_15.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_16.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_2.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_3.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_4.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_5.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_6.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_7.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_8.lo ext/mbstring/libmbfl/filters/mbfilter_iso8859_9.lo ext/mbstring/libmbfl/filters/mbfilter_jis.lo ext/mbstring/libmbfl/filters/mbfilter_koi8r.lo ext/mbstring/libmbfl/filters/mbfilter_qprint.lo ext/mbstring/libmbfl/filters/mbfilter_sjis.lo
Musings on PHP
I personally have no need for PHP, but I know it's a very widely used piece of software. After John Morrison's recent mention of PHP in passing, I decided to do a quick estimate of how difficult getting PHP working on Cygwin would be. To cut a long story short, I got a bit carried away, and now have a functional apache2 php5 module. I didn't really intend to package PHP, but having got this far, I sort of feel I ought to. Which brings me to two major issues concerning any potential Cygwin PHP package: 1) Two apache versions. I've no interest in Apache 1.3.x. Can I just package PHP for 2.x, and worry about 1.3.x only if a potential maintainer steps forward? 2) Shared library headaches. PHP definitely needs its postgresql support available to be useful most non-trivial application. If I want to avoid creating a hard dependency on the postgresql package, the PHP pgsql extension needs to be built as a shared library. But to make that work for both the php command line executable and the apache module, I'd have to significantly tweak the PHP build process, introducing an extra library to contain the core PHP engine, instead of just linking the component object files into both the php exe and the apache module. So... is it worth messing with the build system to this extent, or should I just go the easy route, and have a hard dependency on postgresql's cygpq.dll? Max.
