This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Pre-ITP: apache/mod_php


Brian Dessent schrieb:
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]