Re: MP_APXS vs MP_AP_PREFIX

2003-10-29 Thread Geoffrey Young

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

2003-10-29 Thread Stas Bekman
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

2003-10-29 Thread Geoffrey Young

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

2003-10-29 Thread Stas Bekman
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]