Stas Bekman wrote:
Geoffrey Young wrote:
hi all
the docs say MP_APXS may go away, but I recall some discussion to the contrary. has the status of MP_APXS changed?
do they? I think it's quite the opposite now and I have updated the docs. I guess I've missed some places, please tell me where.
I was looking at
http://perl.apache.org/docs/2.0/user/install/install.html#MP_APXS
Thanks. Fixed (removed that META comment).
>Now that Randy has added APXS for win32, we don't need MP_AP_PREFIX for the DSO build. Though we will need it for the static build, so both are here to stay.
ok
[EMAIL PROTECTED] Apache-IncludeHook]$ perl Makefile.PL -apxs /apache/2.1/worker/perl-5.8.1/bin/apxs
...
>
[EMAIL PROTECTED] Apache-IncludeHook]$ make ... cc -c -I/apache/2.0/worker/perl-5.8.1/include
^^^
why is it 2.0? and not 2.1?
that's the problem I'm addressing
Are you sure that /apache/2.1/worker/perl-5.8.1/bin/apxs doesn't' have 2.0 paths in it?
yup. I take lots of steps to make sure there is no overlap in any of my builds - each variant gets a clean copy of httpd-2.0 to work with and everything is truncated nightly.
I don't understand the problem clearly, MP::MM::WM is using A::BuildConfig to get its data, so it's already aware of the command line args, no?
that's just it, WM doesn't seem to be picking up data parsed via Apache::TestMM::filter_args(). but even if it did, the only data in Apache::BuildConfig is from the mod_perl I installed last (which is the 2.0 install you see in -I above).
what I was thinking about doing was instead of BuildConfig doing
sub new { bless( { 'MODPERL_PRIVLIBEXP' => '/perl/perl-5.8.1/lib/5.8.1',
it could do
sub new { bless( '/apache/2.1/worker/perl-5.8.1/' => { 'MODPERL_PRIVLIBEXP' => '/perl/perl-5.8.1/lib/5.8.1', ... '/apache/2.0/worker/perl-5.8.1/' => { 'MODPERL_PRIVLIBEXP' => '/perl/perl-5.8.1/lib/5.8.1',
instead. the issue is, though, what to use as the key. my thought was to truncate either MP_APXS or MP_AP_PREFIX to the apache install root and use that as the key. or maybe 'default' as the key the first time, and subsequent installs get versioned or something.
is the problem still unclear? I can try to illustrate it better if need be.
No, I understand it now. I think the unique value you are after is the path to httpd, including httpd (for those distros moving it to /usr/bin).
Though you are going to have a hard time maintaining several configs in one file. Instead it's probably better to abstract those into separate files, so when you add a new build you don't need to update that file but only install new build. I was thinking to use an approach taken by Inline, when it builds the shared library. It uses an MD5 hash of the C source as a part of the filename. So when the source changes it knows to rebuild it. We could take an MD5 hash of the path to httpd. Then create:
BuildConfig-16128e67ad092a739842b82295820e31.pm BuildConfig-938883be41ad5efc6c9c0d7affdae8e9.pm
for each build (2 builds above).
Next, when Apache::BuildConfig loads, it could optionally get the http argument, calculate its md5 hash and pick the right BuildConfig file above.
We also need:
BuildConfig-default.pm
which will store the first build, in case the path to httpd is not passed (that's what most users will want: "just use my mp2 build data".
The problem is that MD5 modules aren't in the core. But 99.9999% of users won't need this feature, so if we can make it optional (or e.g. when MP_MAINTAINER is on).
may be keeping Apache::BuildConfig as it is now, but instrument it to optionally check for these special files, which will be useful for developers.
__________________________________________________________________ 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]
