PHP ITP Status Update (was: [Maybe-ITP] PHP)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a quick status update: I've now successfully hacked the buildsystem to produce the cgi-fcgi version of the binary a well as the cli version. I intend to try to tweak the build into producing a core DLL before posting any prospective packages - I think this is fairly necessary, as otherwise the entire php interpreter is included three times, linked into the cli .exe, the cgi-fcgi .exe, and the apache2 module. This bloat is more than I'm comfortable with - and a core DLL will be a prerequisite for any future work on making extensions build shared. Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFEVzrEfFNSmcDyxYARAlpgAKDDILRVUH69xydlMmtzvD4lyNODPQCcCTpW KnTDh8NBfhTznZiO8ZJhT8M= =jRZO -END PGP SIGNATURE-
Re: PHP ITP Status Update (was: [Maybe-ITP] PHP)
Max, I'd like you to take a look at Gentoo Linux PHP ebuild, http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-lang/php/ . It handles single-pass build of cli, cgi and apache module if fastbuild USE option is set and always worked fine to me.You can get great ideas how to run single pass cygwin php build looking at the gentoo php build script. On Tue, 2006-05-02 at 11:56 +0100, Max Bowsher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a quick status update: I've now successfully hacked the buildsystem to produce the cgi-fcgi version of the binary a well as the cli version. I intend to try to tweak the build into producing a core DLL before posting any prospective packages - I think this is fairly necessary, as otherwise the entire php interpreter is included three times, linked into the cli .exe, the cgi-fcgi .exe, and the apache2 module. This bloat is more than I'm comfortable with - and a core DLL will be a prerequisite for any future work on making extensions build shared. Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFEVzrEfFNSmcDyxYARAlpgAKDDILRVUH69xydlMmtzvD4lyNODPQCcCTpW KnTDh8NBfhTznZiO8ZJhT8M= =jRZO -END PGP SIGNATURE-
Re: [Maybe-ITP] PHP
Max Bowsher schrieb: Reini Urban wrote: Well, postgresql is currently one big monolithic package. To make dependencies easier, I could provide the cygpg.dll client lib in a seperate libpg8 package, so that you could talk to a remote postgresql server at least. ok? This would certainly improve the situation. However: cygpq.dll in libpq8 ?? that sounds wrong to me. Surely it should be cygpq8.dll in libpq8, or cygpq.dll in libpq ? It will be libpg4 :) They did fewer client lib changes and no name versioning. See and answer in the seperate postgresql layout thread please. For now I will stay with cygpg.dll and add named versions (cygpg-3.dll for 7.x, cygpg-4.dll for 8.x) when simultanous servers will be supported. -- Reini
Re: [Maybe-ITP] PHP
Max Bowsher wrote: I suggest to add FastCGI support (very useful with lighttpd package) and Umm. My current build doesn't include CGI support, let alone FastCGI. Oooops. Your're perfectly right. Me and a friend of mine tought about it for long in order to produce a multiple (both Apache and CGI) FreeBSD port. What drives me mad is that Windows configure.js actually does support to build ALL of the targets in one single build! And even using one single big .DLL linked by every single api or executable, all very small. Lapo
Re: [Maybe-ITP] PHP
[my first answer was posted from my gmail account, so rejected] Max Bowsher schrieb: I don't have much of a liking for PHP myself, but seeing the large quantity of people who _do_ want it, and being the apache2 maintainer, I feel like I ought to at least make a bit of an effort to make it available. So: I have prospective PHP packages building right now, but: (1) I'm linking to postgresql. PHP without any SQL database interface would be a bit crippled - on the other hand, this requires *everyone* installing PHP to install PostgreSQL. It *ought* to be able to modularize the dependency into a sub-package, but persuading the extensions to build as DLLs is proving more complicated than I have time to tackle right now. Well, postgresql is currently one big monolithic package. To make dependencies easier, I could provide the cygpg.dll client lib in a seperate libpg8 package, so that you could talk to a remote postgresql server at least. ok? Given the above caveats, do you think I should proceed with the ITP process, or not? sure. -- Reini - postgresql mainainer
Re: [Maybe-ITP] PHP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reini Urban wrote: Well, postgresql is currently one big monolithic package. To make dependencies easier, I could provide the cygpg.dll client lib in a seperate libpg8 package, so that you could talk to a remote postgresql server at least. ok? This would certainly improve the situation. However: cygpq.dll in libpq8 ?? that sounds wrong to me. Surely it should be cygpq8.dll in libpq8, or cygpq.dll in libpq ? Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFEU4eGfFNSmcDyxYARAljrAJ0WGReTXXJm1h+eB6g5Za1nWlI72gCeKMzE dg/PUGduSMA526zvGS+PgxQ= =zlQ6 -END PGP SIGNATURE-
Re: [Maybe-ITP] PHP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Max Bowsher wrote: Given the above caveats, do you think I should proceed with the ITP process, or not? Lapo Luchini wrote: I had tought to do this ITP too, but as I'm already enough behind schedule with existing packages I always delayed this to later... I would obviously appreciate it. I suggest to add FastCGI support (very useful with lighttpd package) and Umm. My current build doesn't include CGI support, let alone FastCGI. The PHP build system seems to disable CGI support if you enable any other Server API method :-( (/usr/bin/php is the CLI SAPI version) Looks like I may have to consider some more invasive hacking of the build-system than I wanted to, or build the whole thing multiple times to produce the multiple variants. --enable-zend-multibyte: it enables auto-recognition of PHP files in unicode formats, if they have a leading BOM (as used by many editors). In many years of use of that option on both Windows and FreeBSD I found no bad side-effects, and will be active by default in PHP 6. OK, flag added. Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFEUk5sfFNSmcDyxYARAjVmAJ9KkXO0/yaCHCA8R6juGttzbHDKewCfb70z KDFjrJwvgljeHFeSXKIAU7s= =7gCW -END PGP SIGNATURE-
[Maybe-ITP] PHP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't have much of a liking for PHP myself, but seeing the large quantity of people who _do_ want it, and being the apache2 maintainer, I feel like I ought to at least make a bit of an effort to make it available. So: I have prospective PHP packages building right now, but: (1) I'm linking to postgresql. PHP without any SQL database interface would be a bit crippled - on the other hand, this requires *everyone* installing PHP to install PostgreSQL. It *ought* to be able to modularize the dependency into a sub-package, but persuading the extensions to build as DLLs is proving more complicated than I have time to tackle right now. (2) I'm making no attempt to support Apache 1.x - it's pretty much in the terminal phase of its life-cycle, and I'm unwilling to spend much time working on it. Given the above caveats, do you think I should proceed with the ITP process, or not? Max. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) iD8DBQFEUPgFfFNSmcDyxYARAmaXAKCiOjxUbXjME9FSr9RVP4ewzUts9QCfV2AK Ubi5xn4bEqA2F/DDcQMjdJ8= =8z3U -END PGP SIGNATURE-
Re: [Maybe-ITP] PHP
Max Bowsher maxb1-B2Gdhv0Jo/[EMAIL PROTECTED] writes: I don't have much of a liking for PHP myself, but seeing the large quantity of people who _do_ want it, and being the apache2 maintainer, I feel like I ought to at least make a bit of an effort to make it available. So: I have prospective PHP packages building right now, but: (1) I'm linking to postgresql. PHP without any SQL database interface would be a bit crippled - on the other hand, this requires *everyone* installing PHP to install PostgreSQL. It *ought* to be able to modularize the dependency into a sub-package, but persuading the extensions to build as DLLs is proving more complicated than I have time to tackle right now. (2) I'm making no attempt to support Apache 1.x - it's pretty much in the terminal phase of its life-cycle, and I'm unwilling to spend much time working on it. Given the above caveats, do you think I should proceed with the ITP process, or not? Please do. PHP 4.x is not a very well designed, but PHP 5.x has decent class support for writing reusable code. Jari
Re: [Maybe-ITP] PHP
On Thu, April 27, 2006 5:57 pm, Max Bowsher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I don't have much of a liking for PHP myself, but seeing the large quantity of people who _do_ want it, and being the apache2 maintainer, I feel like I ought to at least make a bit of an effort to make it available. So: I have prospective PHP packages building right now, but: (1) I'm linking to postgresql. PHP without any SQL database interface would be a bit crippled - on the other hand, this requires *everyone* installing PHP to install PostgreSQL. It *ought* to be able to modularize the dependency into a sub-package, but persuading the extensions to build as DLLs is proving more complicated than I have time to tackle right now. (2) I'm making no attempt to support Apache 1.x - it's pretty much in the terminal phase of its life-cycle, and I'm unwilling to spend much time working on it. Given the above caveats, do you think I should proceed with the ITP process, or not? Please, that would be most appreciated. The 'limitations' arn't really very bad :) J.
Re: [Maybe-ITP] PHP
Max Bowsher wrote: Given the above caveats, do you think I should proceed with the ITP process, or not? I had tought to do this ITP too, but as I'm already enough behind schedule with existing packages I always delayed this to later... I would obviously appreciate it. I suggest to add FastCGI support (very useful with lighttpd package) and --enable-zend-multibyte: it enables auto-recognition of PHP files in unicode formats, if they have a leading BOM (as used by many editors). In many years of use of that option on both Windows and FreeBSD I found no bad side-effects, and will be active by default in PHP 6. Lapo
Re: [Maybe-ITP] PHP
Max Bowsher wrote: (1) I'm linking to postgresql. PHP without any SQL database interface would be a bit crippled - on the other hand, this requires *everyone* installing PHP to install PostgreSQL. It *ought* to be able to modularize the dependency into a sub-package, but persuading the extensions to build as DLLs is proving more complicated than I have time to tackle right now. A non-modular PHP is very sub-optimal, since it doesn't allow you to add/remove support libraries. It's either all or nothing. But I tried in the past to get a modular one working and it was a great deal of work, so I suppose a static PHP is better than nothing, but still disappointing. Brian
