You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2003/10/28 20:25:57 UTC
MP_APXS vs MP_AP_PREFIX
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?
I can't recall the exact reason why, but a while ago I switched to MP_APXS
because I couldn't get MP_AP_PREFIX to work properly on muliple build
environments.
the reason I'm asking is because I've started looking at Apache::BuildConfig
to see if there isn't a way to make it versioned for muliple installs. I
know we talked about this before, but IIRC it was in a different context.
the thing that's bugging me today is this
[geoff@jib Apache-IncludeHook]$ perl Makefile.PL -apxs
/apache/2.1/worker/perl-5.8.1/bin/apxs
...
[geoff@jib Apache-IncludeHook]$ make
...
cc -c -I/apache/2.0/worker/perl-5.8.1/include
what I'd like is for ModPerl::MM::WriteMakefile to be able to pick up
command like arguments from filter_args, then have Apache::BuildConfig use
the same options that I used when MP_APXS=/apache/2.1/worker/perl-5.8.1/bin/apxs
a lot to ask, I know :)
so, any ideas as to an approach?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP_APXS vs MP_AP_PREFIX
Posted by Stas Bekman <st...@stason.org>.
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 <Perl>use lib</Perl> for mp1).
>
>
> how about this?
>
> PerlSwitches -I@PERL5LIB@
>
> 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: \@$1\@ $file\n";
> + exists $self->{vars}->{$key} ? $self->{vars}->{$key} :
> + exists $ENV{$1} ? $ENV{$1} :
> + die "invalid token: \@$1\@ $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: \@$1\@ $file\n";
or
$self->{vars}->{$key} dor $ENV{$1} dor die "invalid token: \@$1\@ $file\n";
__________________________________________________________________
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: MP_APXS vs MP_AP_PREFIX
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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 <Perl>use lib</Perl> for mp1).
how about this?
PerlSwitches -I@PERL5LIB@
might not want to die for unrecognized variables anymore, though.
--Geoff
Re: MP_APXS vs MP_AP_PREFIX
Posted by Stas Bekman <st...@stason.org>.
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 <Perl>use lib</Perl> for mp1).
__________________________________________________________________
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: MP_APXS vs MP_AP_PREFIX
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> 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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP_APXS vs MP_AP_PREFIX
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> 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
>
>
> where the hash is httpd run through md5? sick.
>
> I like it :)
oh, you understood it as if I was suggesting to run md5sub on the actual
binary? No, no, it's a bad idea. It's perfectly OK to rebuild httpd, without
rebuilding mod_perl and suddently your hash won't match (if httpd has changed
a bit) and you will have no config at all. I've suggested to md5sum the full
path to httpd.
>> 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".
>
>
> what might work is installing both BuildConfig.pm and
> BuildConfig-$hash.pm. BuildConfig would work as it does presently
> (containing the most-recent install data) and would be there for back
> compat (new WriteMakefile vs old mod_perl).
+1
>> The problem is that MD5 modules aren't in the core.
>
>
> they are in 5.8.0. not sure about 5.6.x. but I thought we made the
> decision to move to 5.8.0 once 5.8.1 came out. I can't remember, though.
since it's a maintainer feature we should make this requirement transparent to
the normal user (i.e. do this extra work only for MP_MAINTAINER=1)
>> 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.
>
>
> 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.
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.
__________________________________________________________________
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: MP_APXS vs MP_AP_PREFIX
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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
where the hash is httpd run through md5? sick.
I like it :)
>
> 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".
what might work is installing both BuildConfig.pm and BuildConfig-$hash.pm.
BuildConfig would work as it does presently (containing the most-recent
install data) and would be there for back compat (new WriteMakefile vs old
mod_perl).
>
> The problem is that MD5 modules aren't in the core.
they are in 5.8.0. not sure about 5.6.x. but I thought we made the
decision to move to 5.8.0 once 5.8.1 came out. I can't remember, though.
> 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).
I agree, most people won't care about this, so making it optional at build
time is best.
>
> 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.
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).
how about MP_VERSIONED_BUILD=1 for the mod_perl end?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP_APXS vs MP_AP_PREFIX
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>
> 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
>
>
>>> [geoff@jib Apache-IncludeHook]$ perl Makefile.PL -apxs
>>> /apache/2.1/worker/perl-5.8.1/bin/apxs
>>> ...
>>
>>
>> >
>>
>>> [geoff@jib 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: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: MP_APXS vs MP_AP_PREFIX
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
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
>
> 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
>> [geoff@jib Apache-IncludeHook]$ perl Makefile.PL -apxs
>> /apache/2.1/worker/perl-5.8.1/bin/apxs
>> ...
>
> >
>
>> [geoff@jib 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.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP_APXS vs MP_AP_PREFIX
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Tue, 28 Oct 2003, Stas Bekman wrote:
>
>
>>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.
>
>
> It's not critical at this stage, but the Win32 apxs needs a
> manual download/install, so not all users will have it. At
> one point Bill Rowe was thinking of including it in httpd,
> but that hasn't happened yet.
You need to nudge Bill once a week or so if you want this to happen. Bill told
me that he is very good at multitasking and the most tasks you give to him,
the better the throughput. Right Bill?
In any case, we aren't abolishing AP_PREFIX.
__________________________________________________________________
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: MP_APXS vs MP_AP_PREFIX
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 28 Oct 2003, Stas Bekman wrote:
> 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.
It's not critical at this stage, but the Win32 apxs needs a
manual download/install, so not all users will have it. At
one point Bill Rowe was thinking of including it in httpd,
but that hasn't happened yet.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: MP_APXS vs MP_AP_PREFIX
Posted by Stas Bekman <st...@stason.org>.
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.
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.
> I can't recall the exact reason why, but a while ago I switched to
> MP_APXS because I couldn't get MP_AP_PREFIX to work properly on muliple
> build environments.
>
> the reason I'm asking is because I've started looking at
> Apache::BuildConfig to see if there isn't a way to make it versioned for
> muliple installs. I know we talked about this before, but IIRC it was
> in a different context. the thing that's bugging me today is this
>
> [geoff@jib Apache-IncludeHook]$ perl Makefile.PL -apxs
> /apache/2.1/worker/perl-5.8.1/bin/apxs
> ...
>
> [geoff@jib Apache-IncludeHook]$ make
> ...
> cc -c -I/apache/2.0/worker/perl-5.8.1/include
^^^
why is it 2.0? and not 2.1? Are you sure that
/apache/2.1/worker/perl-5.8.1/bin/apxs doesn't' have 2.0 paths in it?
> what I'd like is for ModPerl::MM::WriteMakefile to be able to pick up
> command like arguments from filter_args, then have Apache::BuildConfig
> use the same options that I used when
> MP_APXS=/apache/2.1/worker/perl-5.8.1/bin/apxs
>
> a lot to ask, I know :)
>
> so, any ideas as to an approach?
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?
__________________________________________________________________
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