Stas Bekman wrote:
Philippe M. Chiasson wrote:
It's been a long awaited feature, to bring back something similar to the old mod_perl option to have mod_perl statically linked to httpd. Here is my attempt at it.
You rock, this looks so simple :)
The original way I attempted this was to hook into the new httpd build system, but, one issue about that is that it would require autoconf/automake/aclocal.
So, instead, this patch tries to make things work by poking at httpd ever so slightly.
I doubt patching is the best route. Or at least we should support both ways - e.g. if there is autoconf/automake/aclocal then use that, otherwise use patching?
Well, that's certainly possible to support both, any good suggestions on a Makefile.PL option name ? MP_PATCH_HTTPD vs MP_AUTOCONF_HTTPD ?
But if you look at it, the patching really only changes a few build options that can't easily be modified by command-line options (and adds mod_perl to the list of static modules the hard way)
Before we proceed, I'd really like to see a solution not involving the patch. There are many bad side effects to it. A few to mention: If you are working against cvs, you will get the httpd source changed and it'll get on the way all the time. If you attempt to run the install twice you will attempt to patch it twice. And probably other reasons against it too.
I guess autoconf staff is a lot of stuff to write?
Not hard at all, actually. If we are willing to require a re-run of autoconf/automake etc, it's quite simple.
See below.
BTW, libapreq2 added static linking recently, have you looked at how it performs that? (I haven't yet).
Just looked at it, and it's basically doing the same thing I am doing, except one thing, it runs httpd's ./configure on behalf of the user, in mod_perl land, that would translate to:
perl Makefile.PL MP_USE_STATIC=1 MP_CONFIGURE_HTTPD=1 MP_AP_PREFIX=../src/httpd MP_CONFIGURE_HTTPD_ARGS="--with-mpm=worker --enable-module=status [...]"
So it doesn't do any patching, right? What prevents us from doing the same?
There is currently one bug with mod_perl compiled statically. It tries to add the MODPERL2 server define at hook-registry phase, but for statically linked modules, that hook-registry phase is called before ap_server_config_defines is created.
so may be we can dynamically add some hook to insert the define at a later time?
Sadly, not possible right now. the problem is that :
1. server/main() calls ap_setup_prelinked_modules which calls register_hooks 2. server_conf = ap_read_config(process, ptemp, confname, &ap_conftree); 3 server/main() calls pre_config
And #3 is too late to add to the defines, because they are prossed early on in #2, so the only possible time to push to that array is sadly in #1
OK, thanks.
The patch looks fine to me, but if it makes it in static build will require 2.0.50?
And that's not very nice. Another possibility (not a big fan) is that since we are patching/configuring httpd anyways, maybe we can just move ap_setup_prelinked_modules down (as my patch did) ourselves if httpd < 2.0.50...
But we don't want the Apache source patching if we can avoid it. I see no problem with requiring 2.0.50 for the static build, since most people won't need it. And hopefully 2.0.50 will get released soon.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
