You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by "Philippe M. Chiasson" <go...@ectoplasm.org> on 2004/05/06 20:43:53 UTC
[Patch mp2] Statically compiling mod_perl without touching httpd
After thinkering about all the problems with my initial solutions
and looking a bit more closely at httpd's build system, I've come
up with a solution that doesn't involve any patching.
It would be used like this
$> perl Makefile.PL \
MP_USE_STATIC=1 \
MP_AP_CONFIGURE="--with-mpm=prefork --enable-debug [...]"
$> make
The Makefile.PL runs httpd's ./configure and enables mod_perl
The make command will build httpd first and then mod_perl (a required
order)
There are 2 small issues left that I can think of.
First, should make install also install httpd ? Or maybe use another
configurable option MP_AP_INSTALL=1 to control it
Second, right now, make test will only work if called like
$> make test APACHE_TEST_HTTPD=/path/to/httpd/src/httpd
I can't figure out how to pass this httpd location to t/TEST at
configure time to avoid this. Stas ?
Index: Makefile.PL
===================================================================
RCS file: /home/cvs/modperl-2.0/Makefile.PL,v
retrieving revision 1.137
diff -u -I$Id -r1.137 Makefile.PL
--- Makefile.PL 4 Mar 2004 03:36:18 -0000 1.137
+++ Makefile.PL 6 May 2004 18:43:25 -0000
@@ -225,6 +225,10 @@
#ModPerl::BuildMM will use Apache::BuildConfig in subdir/Makefile.PL's
$build->save;
+ if ($build->do_httpd) {
+ $build->configure_httpd();
+ }
+
ModPerl::TestRun->generate_script;
ModPerl::TestReport->generate_script;
Apache::TestSmokePerl->generate_script;
@@ -460,6 +464,11 @@
my $self = shift;
my $string = $self->ModPerl::BuildMM::MY::top_targets;
+ if ($build->do_httpd) {
+ ModPerl::MM::add_dep(\$string, pure_all => 'do_httpd');
+ $string .= qq[\ndo_httpd:\n\tcd "$build->{MP_AP_PREFIX}" && make\n];
+ }
+
ModPerl::MM::add_dep(\$string, pure_all => 'modperl_lib');
$string .= <<'EOF';
Index: lib/Apache/Build.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.162
diff -u -I$Id -r1.162 Build.pm
--- lib/Apache/Build.pm 27 Apr 2004 17:26:28 -0000 1.162
+++ lib/Apache/Build.pm 6 May 2004 18:43:25 -0000
@@ -244,6 +244,33 @@
return $self->{mpm_name} = $mpm_name;
}
+sub do_httpd {
+ my ($self) = @_;
+ return $self->{MP_AP_CONFIGURE} ? 1 : 0;
+}
+
+sub configure_httpd {
+ my ($self) = @_;
+
+ debug "Configuring httpd in $self->{MP_AP_PREFIX}";
+
+ my $mplib = "$self->{MP_LIBNAME}$Config{lib_ext}";
+ my $mplibpath = catfile($self->{cwd}, qw(src modules perl), $mplib);
+
+ local $ENV{BUILTIN_LIBS} = $mplibpath;
+ local $ENV{AP_LIBS} = $self->ldopts;
+ local $ENV{MODLIST} = 'perl';
+
+ #XXX: -Wall and/or -Werror at httpd configure time breaks things
+ local $ENV{CFLAGS} = join ' ', grep { ! /\-Wall|\-Werror/ }
+ split /\s+/, $ENV{CFLAGS};
+
+ my $cd = qq(cd $self->{MP_AP_PREFIX});
+ my $cmd = qq(./configure $self->{MP_AP_CONFIGURE});
+ debug "Running $cmd";
+ system("$cd && $cmd") == 0 or die "httpd: $cmd failed";
+}
+
#--- Perl Config stuff ---
my %gtop_config = ();
Index: lib/ModPerl/BuildOptions.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/BuildOptions.pm,v
retrieving revision 1.26
diff -u -I$Id -r1.26 BuildOptions.pm
--- lib/ModPerl/BuildOptions.pm 4 Mar 2004 06:01:06 -0000 1.26
+++ lib/ModPerl/BuildOptions.pm 6 May 2004 18:43:25 -0000
@@ -220,6 +220,7 @@
STATIC_EXTS 0 Build Apache::*.xs as static extensions
APXS 0 Path to apxs
AP_PREFIX 0 Apache installation or source tree prefix
+AP_CONFIGURE 0 Apache ./configure arguments
APR_CONFIG 0 Path to apr-config
XS_GLUE_DIR 1 Directories containing extension glue
INCLUDE_DIR 1 Add directories to search for header files
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>>
>> Stas Bekman wrote:
>>
>>>>>>> If I remember correctly there were too many problems with that
>>>>>>> approach. And if that's the case. We may need to first install
>>>>>>> httpd, then test modperl and then install modperl. If there are
>>>>>>> no problems, then modperl's make install should install httpd as
>>>>>>> well, as it did in mp1 (plus note my question above regarding
>>>>>>> the flexible build).
>>>>>>
>>>>>>
>>>>>>
>>>>>> So mod_perl's make test (or make) should install httpd then ?
>>>>>
>>>>>
>>>>>
>>>>> let's try first if we can test w/o installing.
>>>>
>>>>
>>>>
>>>> Well, I just managed to run most tests w/o installing against the
>>>> httpd
>>>> in the srcdir ;-)
>>>
>>>
>>>
>>> How bad were the failures? Is it going to be too much of hassle to
>>> support that?
>>
>>
>>
>> There seem to be only 2 problems:
>>
>> t/apr/finfo.t 255 65280 ?? ?? % ??
>> [Thu May 06 16:08:07 2004] [error] [client 127.0.0.1] Use of
>> uninitialized value
>> in pattern match (m//) at
>> mod_perl/2.0/cvs/Apache-Test/lib/Apache/Test.pm line 399.
>> BEGIN failed--compilation aborted at
>> mod_perl/2.0/cvs/t/response/TestAPR/finfo.pm line 13.
>> Compilation failed in require at (eval 96) line 3.
>>
>> t/apr/flatten.t ?? ?? % ??
>> [Thu May 06 16:09:04 2004] [error] server reached MaxClients setting,
>> consider
>> raising the MaxClients setting
>> lt-httpd: error while loading shared libraries:
>> mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
>> modperl_bucket_sv_create
>
>
> Heh, you definitely have missed the thread of your first user who did
> the static build, who had exactly the same problems.
> http://marc.theaimsgroup.com/?t=108325310800002&r=1&w=2
Yeah, I just found out about it when looking for the cause of this problem.
> Olivier has fixed it by linking APR::Bucket statically. I'm glad that
> you have them too, may be you will figure out what's wrong with it.
Yes, it worked fine for me, but there is definitely an underlying
problem that needs to get fixed.
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
>
> Stas Bekman wrote:
>
>>>>>>If I remember
>>>>>>correctly there were too many problems with that approach. And if that's the
>>>>>>case. We may need to first install httpd, then test modperl and then install
>>>>>>modperl. If there are no problems, then modperl's make install should install
>>>>>>httpd as well, as it did in mp1 (plus note my question above regarding the
>>>>>>flexible build).
>>>>>
>>>>>
>>>>>So mod_perl's make test (or make) should install httpd then ?
>>>>
>>>>
>>>>let's try first if we can test w/o installing.
>>>
>>>
>>>Well, I just managed to run most tests w/o installing against the httpd
>>>in the srcdir ;-)
>>
>>
>>How bad were the failures? Is it going to be too much of hassle to support that?
>
>
> There seem to be only 2 problems:
>
> t/apr/finfo.t 255 65280 ?? ?? % ??
> [Thu May 06 16:08:07 2004] [error] [client 127.0.0.1] Use of uninitialized value
> in pattern match (m//) at mod_perl/2.0/cvs/Apache-Test/lib/Apache/Test.pm line 399.
> BEGIN failed--compilation aborted at
> mod_perl/2.0/cvs/t/response/TestAPR/finfo.pm line 13.
> Compilation failed in require at (eval 96) line 3.
>
> t/apr/flatten.t ?? ?? % ??
> [Thu May 06 16:09:04 2004] [error] server reached MaxClients setting, consider
> raising the MaxClients setting
> lt-httpd: error while loading shared libraries:
> mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
> modperl_bucket_sv_create
Heh, you definitely have missed the thread of your first user who did the
static build, who had exactly the same problems.
http://marc.theaimsgroup.com/?t=108325310800002&r=1&w=2
Olivier has fixed it by linking APR::Bucket statically. I'm glad that you have
them too, may be you will figure out what's wrong with it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
>>>>>If I remember
>>>>>correctly there were too many problems with that approach. And if that's the
>>>>>case. We may need to first install httpd, then test modperl and then install
>>>>>modperl. If there are no problems, then modperl's make install should install
>>>>>httpd as well, as it did in mp1 (plus note my question above regarding the
>>>>>flexible build).
>>>>
>>>>
>>>>So mod_perl's make test (or make) should install httpd then ?
>>>
>>>
>>>let's try first if we can test w/o installing.
>>
>>
>>Well, I just managed to run most tests w/o installing against the httpd
>>in the srcdir ;-)
>
>
> How bad were the failures? Is it going to be too much of hassle to support that?
There seem to be only 2 problems:
t/apr/finfo.t 255 65280 ?? ?? % ??
[Thu May 06 16:08:07 2004] [error] [client 127.0.0.1] Use of uninitialized value
in pattern match (m//) at mod_perl/2.0/cvs/Apache-Test/lib/Apache/Test.pm line 399.
BEGIN failed--compilation aborted at
mod_perl/2.0/cvs/t/response/TestAPR/finfo.pm line 13.
Compilation failed in require at (eval 96) line 3.
t/apr/flatten.t ?? ?? % ??
[Thu May 06 16:09:04 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/in_bbs_body.t 255 65280 2 4 200.00% 1-2
[Thu May 06 16:10:34 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/in_bbs_consume.t 1 1 100.00% 1
[Thu May 06 16:11:30 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/in_bbs_inject_header.t 255 65280 36 72 200.00% 1-36
[Thu May 06 16:12:24 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/in_bbs_msg.t 255 65280 ?? ?? % ??
[Thu May 06 16:13:33 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/in_bbs_underrun.t 1 1 100.00% 1
[Thu May 06 16:14:32 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/out_bbs_basic.t 255 65280 ?? ?? % ??
[Thu May 06 16:19:37 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
t/filter/out_bbs_ctx.t 1 1 100.00% 1
[Thu May 06 16:22:01 2004] [error] server reached MaxClients setting, consider
raising the MaxClients setting
lt-httpd: error while loading shared libraries:
mod_perl/2.0/cvs/blib/arch/auto/APR/Bucket/Bucket.so: undefined symbol:
modperl_bucket_sv_create
>
> [...]
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by Stas Bekman <st...@stason.org>.
>>>>If I remember
>>>>correctly there were too many problems with that approach. And if that's the
>>>>case. We may need to first install httpd, then test modperl and then install
>>>>modperl. If there are no problems, then modperl's make install should install
>>>>httpd as well, as it did in mp1 (plus note my question above regarding the
>>>>flexible build).
>>>
>>>
>>>So mod_perl's make test (or make) should install httpd then ?
>>
>>
>>let's try first if we can test w/o installing.
>
>
> Well, I just managed to run most tests w/o installing against the httpd
> in the srcdir ;-)
How bad were the failures? Is it going to be too much of hassle to support that?
>>>>If we go with 'make test' against the source, then it's easy - we know the
>>>>location of the source dir and we know the relative location of httpd
>>>>executable. So just set -httpd /path/to/httpd from Makefile.PL, before
>>>>creating t/TEST. Actually I think that we already handle that case internally
>>>>(at least we did when we tried to make 'make test' work against the source).
>>>
>>>
>>>Yes, that's what I thought, but I couldn't find where that magic is hapenning.
>>>Care to point out to me, as it was the solution I wanted to try. I did it
>>>manually just now and it does work and most test passe fine.
>>
>>
>>It's the filter_args sub that does the magic. So you do:
>>
>> @ARGV, qw(-httpd /path/to/httpd);
>> Apache::TestMM::filter_args();
>>
>>before calling
>>
>> ModPerl::TestRun->generate_script;
>>
>>or you can populate:
>>
>> @Apache::TestMM::Argv = qw(-httpd /path/to/httpd);
>>
>>instead of calling filter_args.
>
>
> I just tried that and the problem is messier. The Makefile uses PASSENV
> and always ends up invoking t/TEST as
>
> APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER=
> APACHE_TEST_APXS= perl t/TEST
>
> and the environment vars seems to have precedence over whatever is in t/TEST
> so the test still fails.
>
> Running ./t/TEST manually does work now though ;-)
Something is wrong then. I've explicitly coded it to ignore any env vars if
they are empty, precisely for this purpose. There must be a bug then. Look at
Test.run:
sub custom_config_add_conf_opts {
my $args = shift;
...
for (@data_vars_opt) {
next unless $Apache::TestConfigData::vars->{$_};
# env vars override custom config
my $env_value = $ENV{ $vars_to_env{$_} };
next unless defined $env_value and length $env_value;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
$args->{$_} ||= $Apache::TestConfigData::vars->{$_};
}
}
>>>>If we go with 'make test' against the post-install httpd, then we have no idea
>>>>what's the location, besides snooping on some httpd config files or using apxs
>>>>if available. i.e. apachectl knows where httpd is located, so we should look
>>>>at how apachectl finds it out and do the same.
>>>>
>>>
>>>
>>>And unless I am wrong, there should be an apxs in the build directory that knows
>>>about httpd's to-be installed PREFIX
>>
>>
>>But apxs doesn't work for static builds, does it? At least it doesn't in
>>apache1.3. I haven't tried in apache2.
>>
>>
>>
>>>>>+ if ($build->do_httpd) {
>>>>
>>>>
>>>>can this be $build->should_configure_httpd?
>>>
>>>
>>>It can very well be anything you want ;-)
>>
>>
>>perfect :)
>
>
> Actually, how about should_build_httpd ?
That's fine.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
>>>Should we think right away about how to do the flexible build, ala mp1? So one
>>>can link httpd statically with mod_perl and other 3rd party modules which
>>>require a separate build (php?). Or should we handle that one later?
>>
>>
>>I'd put that one to a bit later, as things in httpd-2.0 land aren't as easy
>>to configure around. The only way to trick httpd's ./configure to build mod_perl
>>is by using a specific set of environment variables at configuration time.
>>
>>Allowing for a more flexible build like mp1 used to offer will be a bit more
>>complicated without having users cut-n-paste a few environment vars.
>
> >
>
>>For now, I'd leave it at this, and possibly document how to build something
>>like php with it.
>
>
> +1, your change is pretty small, so it's not like we will need to change many
> things to support the flexible build.
>
>
>>In the meantime, I've been looking at a single possible new feature for httpd's
>>./configure that would allow for an even cleaner build and allow 3rd party
>>builds to be possible to
>>
>>$> cd httpd
>>$> ./configure --enable-module=perl:../mod_perl/src/module/perl/mod_perl.a
>>$> cd mod_perl && make
>>$> cd httpd && make
>>
>>But currently, the --enable-module= syntax of httpd isn't quite flexible
>>enough.
>
>
> I'd suggest to look at how php does that?
Will look at it.
>
>
>>>If I remember
>>>correctly there were too many problems with that approach. And if that's the
>>>case. We may need to first install httpd, then test modperl and then install
>>>modperl. If there are no problems, then modperl's make install should install
>>>httpd as well, as it did in mp1 (plus note my question above regarding the
>>>flexible build).
>>
>>
>>So mod_perl's make test (or make) should install httpd then ?
>
>
> let's try first if we can test w/o installing.
Well, I just managed to run most tests w/o installing against the httpd
in the srcdir ;-)
> If not, then yes, it should install it first. In which case we may want to
> make user do that, since they will want to become root.
Yup.
>
>>>If we go with 'make test' against the source, then it's easy - we know the
>>>location of the source dir and we know the relative location of httpd
>>>executable. So just set -httpd /path/to/httpd from Makefile.PL, before
>>>creating t/TEST. Actually I think that we already handle that case internally
>>>(at least we did when we tried to make 'make test' work against the source).
>>
>>
>>Yes, that's what I thought, but I couldn't find where that magic is hapenning.
>>Care to point out to me, as it was the solution I wanted to try. I did it
>>manually just now and it does work and most test passe fine.
>
>
> It's the filter_args sub that does the magic. So you do:
>
> @ARGV, qw(-httpd /path/to/httpd);
> Apache::TestMM::filter_args();
>
> before calling
>
> ModPerl::TestRun->generate_script;
>
> or you can populate:
>
> @Apache::TestMM::Argv = qw(-httpd /path/to/httpd);
>
> instead of calling filter_args.
I just tried that and the problem is messier. The Makefile uses PASSENV
and always ends up invoking t/TEST as
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER=
APACHE_TEST_APXS= perl t/TEST
and the environment vars seems to have precedence over whatever is in t/TEST
so the test still fails.
Running ./t/TEST manually does work now though ;-)
>
>>>If we go with 'make test' against the post-install httpd, then we have no idea
>>>what's the location, besides snooping on some httpd config files or using apxs
>>>if available. i.e. apachectl knows where httpd is located, so we should look
>>>at how apachectl finds it out and do the same.
>>>
>>
>>
>>And unless I am wrong, there should be an apxs in the build directory that knows
>>about httpd's to-be installed PREFIX
>
>
> But apxs doesn't work for static builds, does it? At least it doesn't in
> apache1.3. I haven't tried in apache2.
>
>
>>>>+ if ($build->do_httpd) {
>>>
>>>
>>>can this be $build->should_configure_httpd?
>>
>>
>>It can very well be anything you want ;-)
>
>
> perfect :)
Actually, how about should_build_httpd ?
>
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by Stas Bekman <st...@stason.org>.
>>Should we think right away about how to do the flexible build, ala mp1? So one
>>can link httpd statically with mod_perl and other 3rd party modules which
>>require a separate build (php?). Or should we handle that one later?
>
>
> I'd put that one to a bit later, as things in httpd-2.0 land aren't as easy
> to configure around. The only way to trick httpd's ./configure to build mod_perl
> is by using a specific set of environment variables at configuration time.
>
> Allowing for a more flexible build like mp1 used to offer will be a bit more
> complicated without having users cut-n-paste a few environment vars.
>
> For now, I'd leave it at this, and possibly document how to build something
> like php with it.
+1, your change is pretty small, so it's not like we will need to change many
things to support the flexible build.
> In the meantime, I've been looking at a single possible new feature for httpd's
> ./configure that would allow for an even cleaner build and allow 3rd party
> builds to be possible to
>
> $> cd httpd
> $> ./configure --enable-module=perl:../mod_perl/src/module/perl/mod_perl.a
> $> cd mod_perl && make
> $> cd httpd && make
>
> But currently, the --enable-module= syntax of httpd isn't quite flexible
> enough.
I'd suggest to look at how php does that?
>>If I remember
>>correctly there were too many problems with that approach. And if that's the
>>case. We may need to first install httpd, then test modperl and then install
>>modperl. If there are no problems, then modperl's make install should install
>>httpd as well, as it did in mp1 (plus note my question above regarding the
>>flexible build).
>
>
> So mod_perl's make test (or make) should install httpd then ?
let's try first if we can test w/o installing.
If not, then yes, it should install it first. In which case we may want to
make user do that, since they will want to become root.
>>If we go with 'make test' against the source, then it's easy - we know the
>>location of the source dir and we know the relative location of httpd
>>executable. So just set -httpd /path/to/httpd from Makefile.PL, before
>>creating t/TEST. Actually I think that we already handle that case internally
>>(at least we did when we tried to make 'make test' work against the source).
>
>
> Yes, that's what I thought, but I couldn't find where that magic is hapenning.
> Care to point out to me, as it was the solution I wanted to try. I did it
> manually just now and it does work and most test passe fine.
It's the filter_args sub that does the magic. So you do:
@ARGV, qw(-httpd /path/to/httpd);
Apache::TestMM::filter_args();
before calling
ModPerl::TestRun->generate_script;
or you can populate:
@Apache::TestMM::Argv = qw(-httpd /path/to/httpd);
instead of calling filter_args.
>>If we go with 'make test' against the post-install httpd, then we have no idea
>>what's the location, besides snooping on some httpd config files or using apxs
>>if available. i.e. apachectl knows where httpd is located, so we should look
>>at how apachectl finds it out and do the same.
>>
>
>
> And unless I am wrong, there should be an apxs in the build directory that knows
> about httpd's to-be installed PREFIX
But apxs doesn't work for static builds, does it? At least it doesn't in
apache1.3. I haven't tried in apache2.
>>>+ if ($build->do_httpd) {
>>
>>
>>can this be $build->should_configure_httpd?
>
>
> It can very well be anything you want ;-)
perfect :)
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by "Philippe M. Chiasson" <go...@ectoplasm.org>.
Stas Bekman wrote:
> Philippe M. Chiasson wrote:
>
>>After thinkering about all the problems with my initial solutions
>>and looking a bit more closely at httpd's build system, I've come
>>up with a solution that doesn't involve any patching.
>>
>>It would be used like this
>>
>>$> perl Makefile.PL \
>> MP_USE_STATIC=1 \
>> MP_AP_CONFIGURE="--with-mpm=prefork --enable-debug [...]"
>>$> make
>>
>>The Makefile.PL runs httpd's ./configure and enables mod_perl
>>The make command will build httpd first and then mod_perl (a required
>>order)
>
>
> Excellent. That's very much like mp1 did it.
Yes indeed.
> Should we think right away about how to do the flexible build, ala mp1? So one
> can link httpd statically with mod_perl and other 3rd party modules which
> require a separate build (php?). Or should we handle that one later?
I'd put that one to a bit later, as things in httpd-2.0 land aren't as easy
to configure around. The only way to trick httpd's ./configure to build mod_perl
is by using a specific set of environment variables at configuration time.
Allowing for a more flexible build like mp1 used to offer will be a bit more
complicated without having users cut-n-paste a few environment vars.
For now, I'd leave it at this, and possibly document how to build something
like php with it.
In the meantime, I've been looking at a single possible new feature for httpd's
./configure that would allow for an even cleaner build and allow 3rd party
builds to be possible to
$> cd httpd
$> ./configure --enable-module=perl:../mod_perl/src/module/perl/mod_perl.a
$> cd mod_perl && make
$> cd httpd && make
But currently, the --enable-module= syntax of httpd isn't quite flexible
enough.
>
>>There are 2 small issues left that I can think of.
>>
>>First, should make install also install httpd ? Or maybe use another
>>configurable option MP_AP_INSTALL=1 to control it
>>
>>Second, right now, make test will only work if called like
>>
>>$> make test APACHE_TEST_HTTPD=/path/to/httpd/src/httpd
>>
>>I can't figure out how to pass this httpd location to t/TEST at
>>configure time to avoid this. Stas ?
>
>
> I guess the two are somewhat related. It has been ages since I last tried to
> test against uninstalled httpd. Does it still work at all?
No idea.
> If I remember
> correctly there were too many problems with that approach. And if that's the
> case. We may need to first install httpd, then test modperl and then install
> modperl. If there are no problems, then modperl's make install should install
> httpd as well, as it did in mp1 (plus note my question above regarding the
> flexible build).
So mod_perl's make test (or make) should install httpd then ?
> If we go with 'make test' against the source, then it's easy - we know the
> location of the source dir and we know the relative location of httpd
> executable. So just set -httpd /path/to/httpd from Makefile.PL, before
> creating t/TEST. Actually I think that we already handle that case internally
> (at least we did when we tried to make 'make test' work against the source).
Yes, that's what I thought, but I couldn't find where that magic is hapenning.
Care to point out to me, as it was the solution I wanted to try. I did it
manually just now and it does work and most test passe fine.
> If we go with 'make test' against the post-install httpd, then we have no idea
> what's the location, besides snooping on some httpd config files or using apxs
> if available. i.e. apachectl knows where httpd is located, so we should look
> at how apachectl finds it out and do the same.
>
And unless I am wrong, there should be an apxs in the build directory that knows
about httpd's to-be installed PREFIX
>>+ if ($build->do_httpd) {
>
>
> can this be $build->should_configure_httpd?
It can very well be anything you want ;-)
--
--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [Patch mp2] Statically compiling mod_perl without touching httpd
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> After thinkering about all the problems with my initial solutions
> and looking a bit more closely at httpd's build system, I've come
> up with a solution that doesn't involve any patching.
>
> It would be used like this
>
> $> perl Makefile.PL \
> MP_USE_STATIC=1 \
> MP_AP_CONFIGURE="--with-mpm=prefork --enable-debug [...]"
> $> make
>
> The Makefile.PL runs httpd's ./configure and enables mod_perl
> The make command will build httpd first and then mod_perl (a required
> order)
Excellent. That's very much like mp1 did it.
Should we think right away about how to do the flexible build, ala mp1? So one
can link httpd statically with mod_perl and other 3rd party modules which
require a separate build (php?). Or should we handle that one later?
> There are 2 small issues left that I can think of.
>
> First, should make install also install httpd ? Or maybe use another
> configurable option MP_AP_INSTALL=1 to control it
>
> Second, right now, make test will only work if called like
>
> $> make test APACHE_TEST_HTTPD=/path/to/httpd/src/httpd
>
> I can't figure out how to pass this httpd location to t/TEST at
> configure time to avoid this. Stas ?
I guess the two are somewhat related. It has been ages since I last tried to
test against uninstalled httpd. Does it still work at all? If I remember
correctly there were too many problems with that approach. And if that's the
case. We may need to first install httpd, then test modperl and then install
modperl. If there are no problems, then modperl's make install should install
httpd as well, as it did in mp1 (plus note my question above regarding the
flexible build).
If we go with 'make test' against the source, then it's easy - we know the
location of the source dir and we know the relative location of httpd
executable. So just set -httpd /path/to/httpd from Makefile.PL, before
creating t/TEST. Actually I think that we already handle that case internally
(at least we did when we tried to make 'make test' work against the source).
If we go with 'make test' against the post-install httpd, then we have no idea
what's the location, besides snooping on some httpd config files or using apxs
if available. i.e. apachectl knows where httpd is located, so we should look
at how apachectl finds it out and do the same.
> + if ($build->do_httpd) {
can this be $build->should_configure_httpd?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org