Re: MP_APXS vs MP_AP_PREFIX
optional both at mod_perl build time and an 3rd party module build time? I'd like to think that we can make this work so that mod_perl does the right thing - if mod_perl was built with the md5 versioning, then WriteMakefile does the right thing (or as close as we can get). You forget that you need to pass the locaion of httpd so it'll choose the right md5sum. Otherwise it's a chiken and an egg problem. hmph. I don't see an easy way for mod_perl to intuit the location of httpd at build time. if we have MP_APXS then we're ok, but the user might be building from a source directory and have httpd someplace like /opt. Users should have an exact same behavior as it is now. Only if the special mode is used, and a path to httpd is passed and there is a matching md5sum, then use the other config. how about MP_VERSIONED_BUILD=1 for the mod_perl end? +0. I'd stick to MP_MAINTAINER=1 and only add new features if we really have a need for it. So far I don't see normal users installing 2.1 on their machines along with 2.0. We can always add it later if the need arises. ok. but remember it's not just 2.0 versus 2.1 - it can also be 2.0 with multiple mpms. granted, using a different mpm isn't likely to cause compilation errors later on... hmm. if mpms won't cause compile problems, I wonder if just specifying the apache version is enough. so, instead of having an md5 hash against the path to httpd, we just did Apache::BuildConf-2_0_48 (or maybe Apache::BuildConf::2_0_48). it still means that you could have multiple versions of 2.0.48 with different compile-time settings and you'd get the wrong build options, but typically with third-party installs you're only interested in the location of the header files and other minor stuff like platform... --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MP_APXS vs MP_AP_PREFIX
Geoffrey Young wrote: [...] ok. but remember it's not just 2.0 versus 2.1 - it can also be 2.0 with multiple mpms. granted, using a different mpm isn't likely to cause compilation errors later on... hmm. if mpms won't cause compile problems, I wonder if just specifying the apache version is enough. so, instead of having an md5 hash against the path to httpd, we just did Apache::BuildConf-2_0_48 (or maybe Apache::BuildConf::2_0_48). it still means that you could have multiple versions of 2.0.48 with different compile-time settings and you'd get the wrong build options, but typically with third-party installs you're only interested in the location of the header files and other minor stuff like platform... But you just said by yourself that you may want to have different mpm builds. I've thought about this issue more and came up to a conclusion that we shouldn't make BuildConfig special. After all you have exactly the same problem with any other 3rd party module whose XS build against one mpm won't be compatible with another. I'm still thinking whether try to convert Apache::Scoreboard to use accessors and no compile time defined structs specific to an mpm it was built against. At the moment I need a way to have more than one Scoreboard.so under the same perl build. Therefore the solution IMHO is to use PREFIX and install mpm-specific builds into different locations from the default. A good choice of that PREFIX would be the location of the httpd build. So if you had httpd/worker-2.0.48 httpd/prefork-2.0.48 You'd tell MakeMaker to install mod_perl or a third party module into either: httpd/worker-2.0.48/lib/perl or httpd/prefork-2.0.48/lib/perl An voila the problem solved using the existing infrastructure. Moreover this is not a normal case for an end user. And you automate everything anyway. So if you have to specify a different PREFIX to load things, it shouldn't be a problem. The only missing thing to make the picture complete is PERL5LIB, which bites us back, so we need to instrument Apache-Test to be able to set PerlSwitches -I for us (or use lib for mp1). __ Stas BekmanJAm_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]
Re: MP_APXS vs MP_AP_PREFIX
The only missing thing to make the picture complete is PERL5LIB, which
bites us back, so we need to instrument Apache-Test to be able to set
PerlSwitches -I for us (or use lib for mp1).
how about this?
PerlSwitches [EMAIL PROTECTED]@
might not want to die for unrecognized variables anymore, though.
--Geoff
Index: lib/Apache/TestConfig.pm
===
RCS file:
/home/cvspublic/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.181
diff -u -r1.181 TestConfig.pm
--- lib/Apache/TestConfig.pm21 Oct 2003 22:09:41 - 1.181
+++ lib/Apache/TestConfig.pm30 Oct 2003 04:57:10 -
@@ -912,11 +912,14 @@
my $file = $Apache::TestConfig::File
? "in file $Apache::TestConfig::File" : '';
+# @variable@ substitution
+# look first in the stored config
+# then in %ENV
s[@(\w+)@]
[ my $key = lc $1;
- exists $self->{vars}->{$key}
- ? $self->{vars}->{$key}
- : die "invalid token: [EMAIL PROTECTED]@ $file\n";
+ exists $self->{vars}->{$key} ? $self->{vars}->{$key} :
+ exists $ENV{$1} ? $ENV{$1} :
+ die "invalid token: [EMAIL PROTECTED]@ $file\n";
]ge;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MP_APXS vs MP_AP_PREFIX
Geoffrey Young wrote:
The only missing thing to make the picture complete is PERL5LIB, which
bites us back, so we need to instrument Apache-Test to be able to set
PerlSwitches -I for us (or use lib for mp1).
how about this?
PerlSwitches [EMAIL PROTECTED]@
might not want to die for unrecognized variables anymore, though.
I'd use a totally different name here, so that noone will get mislead that
PERl5LIB is actually working under -T. e.g. PREFIX_LIBS? or even better don't
use %ENV, but add a new option? -perllibs? or both? and make it smart enough
to traverse the top dir for lib, arch. probably the easiest to add it to
modperl_inc.pl with 'use lib' which will do the job.
[ my $key = lc $1;
- exists $self->{vars}->{$key}
- ? $self->{vars}->{$key}
- : die "invalid token: [EMAIL PROTECTED]@ $file\n";
+ exists $self->{vars}->{$key} ? $self->{vars}->{$key} :
+ exists $ENV{$1} ? $ENV{$1} :
+ die "invalid token: [EMAIL PROTECTED]@ $file\n";
]ge;
I wish we had dor() already available. I'm never entirely sure the precedence
of the nested ? : ? : and would rather avoid it.
with dor it'd look like:
$self->{vars}->{$key} // $ENV{$1} // die "invalid token: [EMAIL PROTECTED]@ $file\n";
or
$self->{vars}->{$key} dor $ENV{$1} dor die "invalid token: [EMAIL PROTECTED]@ $file\n";
__
Stas BekmanJAm_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]
