I guess we really need to think harder about third party module support. I know I've struggled with this lately as has Stas, although ModPerl::MM::WriteMakefile seems to sorta work.
maybe we should just revisit third party modules alltogether and come up with a feature list and API, then implement from scratch - possibly as a ModPerl::MM subclass or something.
Well, nobody has followed up on my proposal and related problems, so may be you should first take a look at it.
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=104411330329305&w=2
If I didn't have the questions, I'd have committed it long time ago. Your advice is that I'm after.
since you asked :)
ok, I think what I'd really like to see for third party modules is something as simple as
use ModPerl::MM::Dist qw(WriteMakefile);
WriteMakefile ( # standard MakeMaker stuff 'NAME' => 'Apache::Clean', 'VERSION_FROM' => 'Clean.pm', 'PREREQ_PM' => { HTML::Clean => 0.8, mod_perl => 1.99 },
That's exactly what I was trying to achieve.
Please explain the next two lines:
# override mod_perl specific defaults 'Apache::Test' => 0, # Apache::Test harness is built by default
You mean the import of 'test' and 'clean' targets?
'AUTO_APACHE2' => 0, # installs to Apache/ or Apache2 by default
You don't need to control this one. If mod_perl 2.0 was installed into Apache2/, it should figure that out by itself and install the 3rd party module into the same location.
Why would you want to have a control over it?
)
what I'm really talking about is adding a single line to a standard Makefile.PL (the use() one) and everything is good to go automagically. this will ease the burden considerably on module writers.
That will work for simple pure-perl things mostly. Once you want to mess with generated Makefile, you want to have a full control over it, while having MM help you with the mod_perl specific bits.
the overridden_method stuff really doesn't appeal to me, and I can't say that I see why it needs to be that way if we were to design things better (though it may mean more work for us).
That was an attempt to make things sub-classable.
can't we just import what we want into the MY:: namespace? my latest Makefile.PL
http://search.cpan.org/src/GEOFF/Apache-Clean-2.02b/Makefile.PL
does everything I want it to - the only thing I can immediately see that's missing are XS hooks.
that *only thing* is not so simple. Try to port an XS module and you will see that you end up with writing woodoo code to generate the right makefile targets and they will most likely break if mod_perl changes things just a bit.
but at any rate, the
*MY::constants = \&ModPerl::MM::MY::constants;
was both essential and worked just fine. can't we do something similar behind the scenes in a subclass so that it's all transparent?
Not, if you want to re-use the mod_perl target, and modify it to suit your needs. e.g. adding some actions, removing some or the hardest modify.
Maybe a good design is to have ModPerl::MM as the base class, then make ::Build for the mod_perl proper build stuff and ::Dist for third party modules (or ::CPAN or something).
That's the idea. It would work perfectly if the EU::MM was designed this way. But it doesn't.
If you give it a try you will see that the way EU::MM override works, makes it almost impossible to sub-class things (more than one level), which I was trying to work around with overridden_methods.
__________________________________________________________________ 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]
