I think I have finally worked out the kinks in the crappy PHP build
system. I managed to banish that awful "mkdll.sh" business. The
results after "make" are simply cygphp4.dll and the php4_*.dll ready to
be used. Oh, and none of that rebasing hassle seems to be required. Cheers to whatever binutils/gcc changes that made that one possible.
!!! see see !!! thanks a lot.
I can now cleanly build PHP 4.3.8 as an Apache DSO with the following modules/extensions:
A) Internal / Built-In: ctype, mime_magic, overload, posix, session, sockets, standard, tokenizer
just please add --with-memory-limit because this causes a lot of problems on the poor sf.net server (php-4.1.2 with memory-limit=8MB), and it is best to verify your app at home with the settings under the worst circumstances. which is sf.net.
B) Compiled in cygphp4.dll (bundled libs) / won't work shared: bcmath, calendar, dba (gdbm, cdb, cdb_make, inifile, flatfile), dbase, dbx, dio, exif, filepro, ftp, mysql, pcre, xml
good to have these static.
Note however: xml uses to system expat and gdbm uses to system gdbm. The other dbm's could also be added (Berkeley db 4.x, 3.x, 2.x) but they
didn't work right out of the box and would require more m4 patches so I
didn't bother. I left the pcre as the PHP bundled lib as the config
option for it is very scary and says you should only switch to system
pcre if you really know what you're doing. :-)
yes, berkeley is a beast. db4 would be fine. but if gdbm is supported, this would cover most of the cases.
C) Fully shared (activated in php.ini and dlopen'd from a DLL): bz2, curl, domxml, gd, gettext, gmp, iconv, imap, ldap, mcrypt, openssl, pgsql, zlib
Note also: Currently gd is picking up the X11 libXpm, but with some work it could be told to find the noX version (and add dependency on that package instead.) That would at least eliminate a dependency on libX11 for the -gd package, which could save considerable hassle if someone didn't want any of the xorg stuff. Or *gulp* I suppose it might be possible to offer both, I think Debian does this.
please noX! if there's no configure switch just patch the X libs away.
Anyway, I'm getting pretty close to being able to ITP a whole slew of stuff but I'd like to get some opinions on some matters first. Below are some issues to consider:
- mysqlclient. At the moment I'm compiling the "PHP bundled" MySQL client library, but I think it would be better if Cygwin had mysqlclient and mysqlclient-devel packages. That way mod_php could link against those, and the issue of "no other Apache modules can use MySQL if you use the bundled php version" is solved. I'll take a look at packaging this as well, I've read that the -client packages compile cleanly. I don't think the -server side builds clean yet though.
server builds clean also, but runs not very good. having mysqlclient and mysqlclient-devel is a VERY good idea.
- versioning: Apache 1.3 vs 2.x and php4 vs php5. For apache, I had
planned to just adopt the "apache" = 1.3 and "apache2" = 2.x method. So
/etc/apache/*.conf, /usr/lib/apache/mod*.dll, /usr/share/apache, etc. And when 2.x is ready, /etc/apache2/*.cond, /usr/lib/apache2/*, etc. Contrast to Debian which has /usr/lib/apache/{1.3,2.0}.
perfect.
For php I've
used "php4" throughout, so /etc/php4/*.ini, /usr/lib/php4/*, and so on. If/when php5 is ready I think it should co-exist with s/php4/php5/ in
the names.
php4 and php5? I would prefer /usr/lib/php and /usr/lib/php5 but I have not a strong opinion on that. just most apps expect /usr/local/php/lib/php.ini and /usr/php/lib/php.ini /etc/php.ini and /etc/php5.ini is also okay.
cgi in /usr/lib/php/bin/php.exe or /usr/bin/php.exe ?
cli / cgi seperation?
then it must be /usr/lib/php/bin/php.exe (cgi) and
/usr/bin/php.exe (cli)- Package naming. We already have "apache" and I was planning on "mod_php4" for the main PHP module. Alternatives: libapache-mod_php4, apache-php4, apache-mod_php4, etc. Same for mod_ssl and other Apache modules. And the question still remains what to call the additional PHP extension packages, as any of the extensions from the group in C) above can be made its own package. So for example we could offer a "mod_php4-pgsql" package that would add postgres support. Some of them though don't really deserve their own package, I mean I think it would be safe to require bzip2 and zlib and not offer them as individually selectable modules.
I like this most: apache{,2}-php4 libhttpd-php4 php{4,5}-cli (for the cgi and cli and pear) php4{4,5}-extensions
apache-mod_php4 is quite a long name but also good. if you really want that many packages to maintain :)
apache-ssl should really be a seperate package, since this requires the ugly mod_ssl EAPI patch AND the rebase problems.
less packages: apache-php4 (incl. pear + cli + exts) apache-php5 (incl. pear + cli + exts) libhttpd-php4 apache2-php4 (incl. pear + cli + exts) apache2-php5 (incl. pear + cli + exts)
this way most other distribs do it.
pear could be shared between php4 and php5
Or, there could just be the single mod_php4 package, but only the modules from C) that correspond to installed packages are enabled in the postinstall, so that they don't pull in a bunch of stuff in the "requires" line. Under that scenario if you wanted to e.g. add postgres support you would install the postgres package, then reinstall mod_php4 (or re-run its module config script) and the pqsql module would be automagically activated. I can see pros and cons to both ways of doing it - what do you think?
if postgresql provides the needed dll, just edit php.ini to activate this particular extension, which is either in apache-php4 or php4-extensions. I don't like to much magic postinstall stuff, but if it works :)
Also in this category is the CLI version of PHP (which I'm not building at the moment) as well as PEAR. They could be offered as seperate "php4-cli" and "php4-pear" packages. However I'm not entirely sure how the extensions would work there: I /think/ but am not sure that they would share the same extensions (the Apache module and /usr/bin/php4 that is.)
yes, pear should be shared. extensions also. and you don't need to bundle them twice. either in the cli or the main apache package is enough.
FYI: the extensions path is pulled from the php.ini, which location is compiled in. so mod_php4 and php.exe will find it.
the extensions filename is in php.ini. most unix packages don't enable the extensions, but most windows do so.
ext filenames: best is to leave them as the native windows build: php_pdflib.dll, so that php.ini doesn't need to be patched.
but this could clash with the win32 native parts, so one could also name them .so, and import them via dlopen("php_gd.so") in apache at run-time (unix style).
unix prefers dlopen, windows prefers loading at startup via extension=.
I would choose .dll as extension. they do work in the seperate extensions dir, even on windows.
I'm sure there are other issues, but those are the ones that come to mind right now... I'm just trying to get some concensus here first before posting "-1" packages that end up needing to be recreated. All comments welcome.
-- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/
