httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Ralf S. Engelschall)
Subject Re: APACI: Commit Strategy
Date Sat, 28 Mar 1998 11:42:55 GMT

In article <> you wrote:

>[...]APACI looks ready, except for the fact that I'm not 100% sure what to do
> with the mod_perl support in APACI (either remove it [the --add-modperl
> option] or receive an ok from Doug that he really puts our new
> 1.3-src/modules/perl/Makefile.tmpl into _his_ mod_perl distribution, so
> APACI's --add-modperl can fetch it from there; Just a semi-useable option is
> not acceptable).

Because Doug is out of town and cannot be reached for a statement and on the
other hand Rasmus' PHP3 has the same problem, I decided to drop the special
--add-modperl option in APACI (because for PHP3 would would need a --add-php3
and for XZY a --add-xyz, etc.) and instead added a little bit more granular
support for third-party authors: --activate-module. This options is intended
for situations where a third-party module is distributed and created outside
of Apache's source tree but copied by the third-party distribution to the
Apache source tree. To actually activate this incoming sources
--add-activate=src/modules/.../mod_foo.c can be used which on-the-fly adds
an entry for a mod_foo.c to the configuration and enables it per default.
This works now fine for both PHP3 and mod_perl.

Only disadvantage for mod_perl. Until Doug doesn't include our new 1.3
src/modules/perl/Makefile.tmpl into his distribution the user cannot build
mod_perl as a shared object. Same for Rasmus: he has to put mod_php3.c into
src/modules/php3/ and provide a similar Makefile then mod_perl or mod_proxy.

But this way APACI is now clean from such semi-useable options.
I now go into my test phase for this weekend...

                                       Ralf S. Engelschall

View raw message