>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:[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]
