You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/03/24 08:48:06 UTC
[rfc] new ModPerl::MM
OK, I've refurbished ModPerl::MM to work with 3rd party modules. It's explained in
http://perl.apache.org/docs/2.0/api/ModPerl/MM.html
The punch line is that most 3rd party Apache:: modules's Makefile.PL will look
as simple as:
require ModPerl::MM;
ModPerl::MM::WriteMakefile(
NAME => "Apache::Peek",
VERSION_FROM => "Peek.pm",
);
no matter if they use XS or not. Of course more code will needed if the same
Makefile.PL has to support mod_perl 1.0 as well.
The only thing that troubles me is the automagical overriding of MY:: methods
behind the scenes. If you remember I've first used B::Deparse and later have
resorted to a much more robust solution, overriding
ExtUtils::MakeMaker::mv_all_methods, which is cool for building mod_perl
itself, since if in the future ExtUtils::MakeMaker changes force us to change
things, it's all under our control. This is not the case with 3rd party modules.
The drawback of not-using this solution is that all 3rd party Makefile.PL will
have to manually assign the overrides. e.g.:
require ModPerl::MM;
ModPerl::MM::WriteMakefile(
NAME => "Apache::Peek",
VERSION_FROM => "Peek.pm",
);
*MY::constants = \&ModPerl::MM::MY::constants;
*MY::post_initialize = \&ModPerl::MM::MY::post_initialize;
also if in the future we supply more default overrides, the 3rd party modules
Makefile.PLs will have to be fixed. Using the overriding behind the scenes
they won't need to be touched.
If I knew that ExtUtils::MakeMaker::mv_all_methods will stay as it is, that
won't be an issue.
One more note. Is that a good name for an api: ModPerl::MM::get_def_opt? See
the manpage URL for details.
p.s. Of course you need the very latest cvs version to have this functionality.
Your comments are very appreciated
__________________________________________________________________
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: [rfc] new ModPerl::MM
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> You should be able to do: perl Makefile.PL && make test
>
>
> bah, that's just bad form ;)
Actually, it's not. Normally you do:
perl Makefile.PL && make && make test
# test broken, fix test
make test
# test is still broken, fix test
make test
# etc
If you run 'make test' and the source have changed, make should be able to
figure out that bring the 'all' target up to date. Otherwise, you may forget
to run 'make' and will test an outdated version.
__________________________________________________________________
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: [rfc] new ModPerl::MM
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> You should be able to do: perl Makefile.PL && make test
bah, that's just bad form ;)
> In your case, this won't work. pure_all tells the test target to run the
> 'all' target first (which is the default target when you say 'make',
> equivalent to 'make all').
ok, I'll look into that.
>> there is some difference, but I really forget what it is. what I do
>> remember is that when I made the rarget test: make complained about
>> seeing two targets (test: and test::), so I figured that MakeMaker
>> wasn't picking it up properly.
>
>
> Why do you end up with two test targets in first place?
exactly.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [rfc] new ModPerl::MM
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Stas Bekman wrote:
> > Geoffrey Young wrote:
> >
> >> # The whitespace in front of @echo MUST be a single tab!
> >> return <<'EOF';
> >> test::
> >> @echo This test suite requires Apache::Test
> >> @echo available from the mod_perl 2.0 sources
> >> @echo or the httpd-test distribution.
> >> EOF
> >
> >
> > I think you should also include the 'pure_all' target, so 'make test'
> > doesn't preclude 'make':
>
> I don't understand what you mean here. what does pure_all cover and how
> would this test target interfere with it? I suppose that there are lots
> of targets, but I figured that Apache::Test just installs its own test
> target, so doing the same would be sufficient. but I dunno.
You should be able to do: perl Makefile.PL && make test
In your case, this won't work. pure_all tells the test target to run the 'all'
target first (which is the default target when you say 'make', equivalent to
'make all').
> >
> > return <<'EOF';
> > test : pure_all
> > @echo \*** This test suite requires Apache::Test available from the
> > @echo \*** mod_perl 2.0 sources or the httpd-test distribution.
> > EOF
> >
> > btw, what's the difference between : and :: in the makefile target?
>
> there is some difference, but I really forget what it is. what I do
> remember is that when I made the rarget test: make complained about
> seeing two targets (test: and test::), so I figured that MakeMaker
> wasn't picking it up properly.
Why do you end up with two test targets in first place?
__________________________________________________________________
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: [rfc] new ModPerl::MM
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>> # The whitespace in front of @echo MUST be a single tab!
>> return <<'EOF';
>> test::
>> @echo This test suite requires Apache::Test
>> @echo available from the mod_perl 2.0 sources
>> @echo or the httpd-test distribution.
>> EOF
>
>
> I think you should also include the 'pure_all' target, so 'make test'
> doesn't preclude 'make':
I don't understand what you mean here. what does pure_all cover and
how would this test target interfere with it? I suppose that there
are lots of targets, but I figured that Apache::Test just installs its
own test target, so doing the same would be sufficient. but I dunno.
>
> return <<'EOF';
> test : pure_all
> @echo \*** This test suite requires Apache::Test available from the
> @echo \*** mod_perl 2.0 sources or the httpd-test distribution.
> EOF
>
> btw, what's the difference between : and :: in the makefile target?
there is some difference, but I really forget what it is. what I do
remember is that when I made the rarget test: make complained about
seeing two targets (test: and test::), so I figured that MakeMaker
wasn't picking it up properly.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [rfc] new ModPerl::MM
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> # The whitespace in front of @echo MUST be a single tab!
> return <<'EOF';
> test::
> @echo This test suite requires Apache::Test
> @echo available from the mod_perl 2.0 sources
> @echo or the httpd-test distribution.
> EOF
I think you should also include the 'pure_all' target, so 'make test' doesn't
preclude 'make':
return <<'EOF';
test : pure_all
@echo \*** This test suite requires Apache::Test available from the
@echo \*** mod_perl 2.0 sources or the httpd-test distribution.
EOF
btw, what's the difference between : and :: in the makefile target?
__________________________________________________________________
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: [rfc] new ModPerl::MM
Posted by Stas Bekman <st...@stason.org>.
>> What do you think?
>
>
> I really don't have an opinion here. really, this kind of hackery is
> going to be required if people want make test to behave properly - they
> may not have whatever abstraction you create installed, so they'll still
> need to protect against failures due to an incomplete harness. herein
> lies the problem of a test suite that is installed by default with 2.0
> but can also be used for 1.0 :)
I'm planning a special package which will work with both versions. Makefile.PL
will require this package to proceed. Optionally CPAN module developers can
use CPAN::MakeMaker to bundle this special package with their distro.
I'm also planning to add it to both 1.0 and 2.0, to minimize the dependancy.
__________________________________________________________________
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: [rfc] new ModPerl::MM
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>> # The whitespace in front of @echo MUST be a single tab!
>> return <<'EOF';
>> test::
>> @echo This test suite requires Apache::Test
>> @echo available from the mod_perl 2.0 sources
>> @echo or the httpd-test distribution.
>> EOF
>> }
>
>
> What happens to 'make test' in that case? It returns success, right?
it should, but I haven't verified that in a while. I'll check tomorrow.
[snip]
> What do you think?
I really don't have an opinion here. really, this kind of hackery is
going to be required if people want make test to behave properly -
they may not have whatever abstraction you create installed, so
they'll still need to protect against failures due to an incomplete
harness. herein lies the problem of a test suite that is installed by
default with 2.0 but can also be used for 1.0 :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [rfc] new ModPerl::MM
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> # The whitespace in front of @echo MUST be a single tab!
> return <<'EOF';
> test::
> @echo This test suite requires Apache::Test
> @echo available from the mod_perl 2.0 sources
> @echo or the httpd-test distribution.
> EOF
> }
What happens to 'make test' in that case? It returns success, right?
What I want to avoid is having these cpan-testers problem reports, which I get
regarding the broken test suites, when in fact there are just missing.
If that works, that's pretty neat. So we can have this helper target in
ModPerl::MM? So you just say:
*MY::test = \&ModPerl::MM::MY::test?
Actually this is not good, as MM::MY is special. May be we should have
ModPerl::MMExtra, with this kind of helper routines in it? So we don't pollute
ModPerl::MM?
The other problem with using a core module for that, is that it won't be
available for mod_perl 1.0. Should we make it a CPAN module and use
CPAN::MakeMaker to wrap it in.
That sounds like a good idea to me. Because I also want to abstract all the
mod_perl 1.0 vs. 2.0 detection craft, including env vars and Makefile.PL
options into a neat sub, that I can use from my CPAN modules. If all
Apache::/ModPerl:: CPAN modules will use it, users will have an identical
usage scheme (e.g. the way they tell Makefile.PL, whether they want to build
against 1.0 or 2.0, etc).
What do you think?
__________________________________________________________________
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: [rfc] new ModPerl::MM
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Unrelated to the blib issue I want a nice fallback in the case
> Apache::Test is not available.
I've been working on that for a very long time :)
here's my standard Makefile.PL for 1.0 modules, which is the neatest way
I've found to address the issue. this also works for modules that are
intended for both 1.0 and 2.0.
sub MY::test {
if (eval "require Apache::TestMM") {
Apache::TestMM::filter_args();
Apache::TestMM::generate_script('t/TEST');
Apache::TestMM->import(qw(test clean));
return Apache::TestMM->test;
}
# The whitespace in front of @echo MUST be a single tab!
return <<'EOF';
test::
@echo This test suite requires Apache::Test
@echo available from the mod_perl 2.0 sources
@echo or the httpd-test distribution.
EOF
}
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [rfc] new ModPerl::MM
Posted by Stas Bekman <st...@stason.org>.
>>> Just stuff it in t/conf/modperl_extra_startup.pl
>>
>> IIRC, this doesn't work because extra.conf.in is sucked in via Include
>> before the startup - if extra.conf.in uses PerlModule (which is
>> required for 1.0 custom directives) then it's too late. but again, I
>> already have a workaround - I just think it should be easier and more
>> DWIMmy.
Geoff, please check if this works for you:
use Cwd;
use File::Spec::Functions;
my $blib_path = catdir Cwd::cwd(), "blib";
my $blib_code = "use blib qw($blib_path);";
if ($mp_version == 1) {
$blib_code .= "\n";
}
else {
$blib_code .= "\nuse Apache2;\n";
}
if (eval {require Apache::TestMM}) {
Apache::TestMM->import(qw(test clean));
my @scripts = qw(t/TEST);
# accept the configs from command line
Apache::TestMM::filter_args();
Apache::TestMM::generate_script('t/TEST');
my $blib = "t/conf/blib.pl.in";
open EXTRA, ">$blib" or die "can't open $blib: $!";
print EXTRA $blib_code;
print EXTRA "1;";
close EXTRA;
}
seems to work fine here. I suppose that this can be wrapped into Apache::Test
function which will be explicitly invoked from Makefile.PL, we will see. I'll
play some more with it later.
__________________________________________________________________
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: [rfc] new ModPerl::MM
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> now I use:
>>
>> PerlSwitches -Mblib=@ServerRoot@/../blib -MApache2
>
>
> yeah, that's a nice way to do it with 2.0
>
>>
>> I'm not quite sure why this should be an Apache::Test responsibility?
>
>
> well, Apache::Test already adds a bunch of libraries via
> modperl_startup.pl (or whatever the generated one is), and by default
> build libraries are put into blib, so I don't see why I need to do this
> myself.
I need to check. That should be optional, since blib croaks if it doesn't find
blib, and in cases where Apache::Test is used for things which aren't perl
(e.g. while testing httpd) there is no blib.
>> Just stuff it in t/conf/modperl_extra_startup.pl
>
>
> IIRC, this doesn't work because extra.conf.in is sucked in via Include
> before the startup - if extra.conf.in uses PerlModule (which is required
> for 1.0 custom directives) then it's too late. but again, I already
> have a workaround - I just think it should be easier and more DWIMmy.
We definitely want DWIM.
I'm working on something like the following, need to polish it though.
Unrelated to the blib issue I want a nice fallback in the case Apache::Test is
not available. I haven't tested the blib part of the code yet, probably will
have the issues you have mentioned above.
my $blib_code = '';
if ($mp_version == 1) {
$blib_code = "use blib;\n";
}
else {
$blib_code = "use blib;\nuse Apache2;\n";
}
if (eval {require Apache::TestMM}) {
Apache::TestMM->import(qw(test clean));
my @scripts = qw(t/TEST);
# accept the configs from command line
Apache::TestMM::filter_args();
Apache::TestMM::generate_script('t/TEST');
my $blib = "t/conf/blib.pl.in";
open EXTRA, ">$blib" or die "can't open $blib: $!";
print EXTRA $blib_code;
print EXTRA "1;";
close EXTRA;
}
else {
warn "***: You should install Apache::Test to do real testing\n";
my $test = "t/TEST";
unlink $test;
open TEST, ">$test" or die "can't open $test: $!";
print TEST <<EOF;
BEGIN { print "0..1\\n" };
$blib_code
require Apache::Peek;
print "ok 1\\n";
EOF
close TEST;
chmod 0755, $test;
}
__________________________________________________________________
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: [rfc] new ModPerl::MM
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> now I use:
>
> PerlSwitches -Mblib=@ServerRoot@/../blib -MApache2
yeah, that's a nice way to do it with 2.0
>
> I'm not quite sure why this should be an Apache::Test responsibility?
well, Apache::Test already adds a bunch of libraries via
modperl_startup.pl (or whatever the generated one is), and by default
build libraries are put into blib, so I don't see why I need to do
this myself.
>
> Just stuff it in t/conf/modperl_extra_startup.pl
IIRC, this doesn't work because extra.conf.in is sucked in via Include
before the startup - if extra.conf.in uses PerlModule (which is
required for 1.0 custom directives) then it's too late. but again, I
already have a workaround - I just think it should be easier and more
DWIMmy.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [rfc] new ModPerl::MM
Posted by Stas Bekman <st...@stason.org>.
> 1) I'd like to find a portable way to make perl Makefile.PL
> TEST_VERBOSE=1 work. I have a patch for this somplace, but it required
> GetOpts from 5.8.0 and I couldn't figure out how to make it work with
> 5.6. this is just a minor thing.
OK, I'll look at it.
> 2) for XS based 1.0 modules, I need to <Perl> use blib; </Perl> in order
> to let Apache::Test see the .so files in my blib, which is really
> annoying. I'd like to find some way around this. I've not played
> around with XS on mod_perl 2.0, but I'd be interested in seeing if it
> has the same issue. you can try removing the blib stuff from
> extra.conf.in in
>
> http://www.modperlcookbook.org/~geoff/modules/Apache-AuthDigest-0.022.tar.gz
>
>
> if you want to try it out.
now I use:
PerlSwitches -Mblib=@ServerRoot@/../blib -MApache2
I'm not quite sure why this should be an Apache::Test responsibility?
Just stuff it in t/conf/modperl_extra_startup.pl
I'm working on Apache::Peek's all-in-one Makefile.PL/TEST.PL, it gets quite
elaborated. May be this could all be converted into yet another separate module.
__________________________________________________________________
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: [rfc] new ModPerl::MM
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
oh, and as I mentioned before, you can't test assbackwards under
Apache::Test. I've also posted a patch for this :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [rfc] new ModPerl::MM
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> 1) t/TEST -conf -httpd ...
>
> doesn't find mod_perl.so (it works with -apxs)
>
> Previously mentioned by Randy and I'm able to reproduce the problem.
yup, I've seen it too.
>
> 2) I want Apache::Test to figure out -httpd/-apxs by itself if possible,
> after all mod_perl already has this information.
yea!
> I don't like when I
> have to manually supply -httpd/-apxs flags. Of course this DWIM,
> shouldn't break usages where Apache::Test is not working with mod_perl,
> so I'm thinking about using some explicit flag passed from t/TEST to
> tell Apache::Test to discover apxs/httpd by itself.
>
> If there are any other burning issues re: Apache::Test speak up now.
1) I'd like to find a portable way to make perl Makefile.PL
TEST_VERBOSE=1 work. I have a patch for this somplace, but it
required GetOpts from 5.8.0 and I couldn't figure out how to make it
work with 5.6. this is just a minor thing.
2) for XS based 1.0 modules, I need to <Perl> use blib; </Perl> in
order to let Apache::Test see the .so files in my blib, which is
really annoying. I'd like to find some way around this. I've not
played around with XS on mod_perl 2.0, but I'd be interested in seeing
if it has the same issue. you can try removing the blib stuff from
extra.conf.in in
http://www.modperlcookbook.org/~geoff/modules/Apache-AuthDigest-0.022.tar.gz
if you want to try it out.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [rfc] new ModPerl::MM
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> Ah, of course, I've missed this one. Thanks for reminding me. However
>> the patch should be different, to override only macro->{MOD_INSTALL}
>> and allow Makefile.PL to override other macro => {} keys, similar to
>> 'dynamic_lib'. I'll apply the right fix.
>
>
> coolio
>
>>
>>> otherwise, nice work stas - it works like a charm.
>>
>>
>>
>> Thanks Geoff!
>>
>> Now going to polish Apache::Test for 3rd party modules.
>
>
> in what sense? I've been using Apache::Test for mod_perl 1.0 and 2.0
> modules for a while now and haven't had any sort of issues with them.
> (well, that's not really true, but the problems have been long-standing
> ones with 1.0 XS based modules).
1) t/TEST -conf -httpd ...
doesn't find mod_perl.so (it works with -apxs)
Previously mentioned by Randy and I'm able to reproduce the problem.
2) I want Apache::Test to figure out -httpd/-apxs by itself if possible, after
all mod_perl already has this information. I don't like when I have to
manually supply -httpd/-apxs flags. Of course this DWIM, shouldn't break
usages where Apache::Test is not working with mod_perl, so I'm thinking about
using some explicit flag passed from t/TEST to tell Apache::Test to discover
apxs/httpd by itself.
If there are any other burning issues re: Apache::Test speak up now.
__________________________________________________________________
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: [rfc] new ModPerl::MM
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Ah, of course, I've missed this one. Thanks for reminding me. However
> the patch should be different, to override only macro->{MOD_INSTALL} and
> allow Makefile.PL to override other macro => {} keys, similar to
> 'dynamic_lib'. I'll apply the right fix.
coolio
>
>> otherwise, nice work stas - it works like a charm.
>
>
> Thanks Geoff!
>
> Now going to polish Apache::Test for 3rd party modules.
in what sense? I've been using Apache::Test for mod_perl 1.0 and 2.0
modules for a while now and haven't had any sort of issues with them.
(well, that's not really true, but the problems have been
long-standing ones with 1.0 XS based modules).
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [rfc] new ModPerl::MM
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> The punch line is that most 3rd party Apache:: modules's Makefile.PL
>> will look as simple as:
>>
>> require ModPerl::MM;
>> ModPerl::MM::WriteMakefile(
>> NAME => "Apache::Peek",
>> VERSION_FROM => "Peek.pm",
>> );
>>
>> no matter if they use XS or not.
>
>
> I'd suggest the following patch to make the above assertion true - it
> adds the 'macro' option to the default list. without it, installations
> are not automatically intelligent about Apache2/ installations.
Ah, of course, I've missed this one. Thanks for reminding me. However the
patch should be different, to override only macro->{MOD_INSTALL} and allow
Makefile.PL to override other macro => {} keys, similar to 'dynamic_lib'. I'll
apply the right fix.
> otherwise, nice work stas - it works like a charm.
Thanks Geoff!
Now going to polish Apache::Test for 3rd party modules.
__________________________________________________________________
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: [rfc] new ModPerl::MM
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> The punch line is that most 3rd party Apache:: modules's Makefile.PL
> will look as simple as:
>
> require ModPerl::MM;
> ModPerl::MM::WriteMakefile(
> NAME => "Apache::Peek",
> VERSION_FROM => "Peek.pm",
> );
>
> no matter if they use XS or not.
I'd suggest the following patch to make the above assertion true - it adds
the 'macro' option to the default list. without it, installations are not
automatically intelligent about Apache2/ installations.
otherwise, nice work stas - it works like a charm.
--Geoff
Index: MM.pm
===================================================================
RCS file: /home/cvspublic/modperl-2.0/lib/ModPerl/MM.pm,v
retrieving revision 1.27
diff -u -r1.27 MM.pm
--- MM.pm 24 Mar 2003 05:43:51 -0000 1.27
+++ MM.pm 24 Mar 2003 13:37:52 -0000
@@ -99,17 +99,18 @@
}
}
-my @default_opts = qw(CCFLAGS LIBS INC OPTIMIZE LDDLFLAGS TYPEMAPS);
+my @default_opts = qw(CCFLAGS LIBS INC OPTIMIZE LDDLFLAGS TYPEMAPS macro);
my @default_dlib_opts = qw(OTHERLDFLAGS);
my $b = build_config();
my %opts = (
- CCFLAGS => sub { $b->perl_ccopts . $b->ap_ccopts },
- LIBS => sub { join ' ', $b->apache_libs, $b->modperl_libs },
- INC => sub { $b->inc; },
- OPTIMIZE => sub { $b->perl_config('optimize'); },
- LDDLFLAGS => sub { $b->perl_config('lddlflags'); },
- TYPEMAPS => sub { $b->typemaps; },
- OTHERLDFLAGS => sub { $b->otherldflags; },
+ CCFLAGS => sub { $b->perl_ccopts . $b->ap_ccopts },
+ LIBS => sub { join ' ', $b->apache_libs, $b->modperl_libs },
+ INC => sub { $b->inc; },
+ OPTIMIZE => sub { $b->perl_config('optimize'); },
+ LDDLFLAGS => sub { $b->perl_config('lddlflags'); },
+ TYPEMAPS => sub { $b->typemaps; },
+ OTHERLDFLAGS => sub { $b->otherldflags; },
+ macro => sub { { MOD_INSTALL => ModPerl::MM::mod_install(), } },
);
sub get_def_opt {
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org