You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by David Wheeler <da...@kineticode.com> on 2004/12/29 18:43:46 UTC

ModPerl::MB

Hi All,

So I've been talking to the mod_perl developers about providing 
installation tools built on top of Module::Build. Specifically, they 
have a module, ModPerl::MM, that can be used by CPAN modules built on 
top of mod_perl to build themselves. From what I understand, the whole 
point of that module is to detect when both mod_perl1 and mod_perl2 are 
installed, and, when they are, to add "Apache" to the install path 
before installing mod_perl2-specific modules. The documentation is 
here:

   http://perl.apache.org/docs/2.0/api/ModPerl/MM.html

Anyway, in talking to Stas and Geoff about providing the same 
functionality for modules that want to use Module::Build, the question 
came up as to how they should go about it. I think what makes the most 
sense is for a ModPerl::MB module to subclass Module::Build and 
override the appropriate method to append "Apache" to the install path 
when necessary. So the question is, what method and/or property should 
be overridden?

Thanks,

David


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: ModPerl::MB

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> In which case I've lost you, since ModPerl::MM doesn't call
> Apache::src->new->inc. I guess, you've meant:
> 
> http://perl.apache.org/docs/2.0/api/ModPerl/MM.html#C_INC_
> 
> is that right?

yes.

/me sighs

all I was doing was showing how things worked in mp1 and, thus, what mp2
does _equivalently_ behind the scenes.  but if it's not clear don't worry
about it since, as you pointed out, it just doesn't matter with M::B.

--Geoff


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: ModPerl::MB

Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>>note that even without the win32 foo mp1 still needs the call to
>>>Apache::src->new->inc to find the proper header files.
>>
>>
>>wo, wo, wo, nobody was even suggesting to do that for mp1. mp2 was the
>>only one.
> 
> 
> eesh... I wasn't suggesting that.  I was just showing what ModPerl::MM does
> behind the scenes.

In which case I've lost you, since ModPerl::MM doesn't call
Apache::src->new->inc. I guess, you've meant:

http://perl.apache.org/docs/2.0/api/ModPerl/MM.html#C_INC_

is that right?

>>But M::B doesn't support XS yet, so that's moot.
> 
> 
> yup, ok.
> 
> --Geoff


-- 
__________________________________________________________________
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: ModPerl::MB

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> note that even without the win32 foo mp1 still needs the call to
>> Apache::src->new->inc to find the proper header files.
> 
> 
> wo, wo, wo, nobody was even suggesting to do that for mp1. mp2 was the
> only one.

eesh... I wasn't suggesting that.  I was just showing what ModPerl::MM does
behind the scenes.

> But M::B doesn't support XS yet, so that's moot.

yup, ok.

--Geoff

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Module::Build] Re: ModPerl::MB

Posted by Stas Bekman <st...@stason.org>.
David Wheeler wrote:
> On Dec 29, 2004, at 6:49 PM, Geoffrey Young wrote:
> 
>> for a bit of history here, what happens with mp2 is that if it sees a mp1
>> installation it installs everything under site_lib/Apache2/ (like
>> Apache::Filter becomes Apache2/Apache/Filter.pm) as to not collide with
>> existing modules in the mp1 namespace.  along with this is Apache2.pm, 
>> which
>> adjusts @INC so that Apache::Filter resolves to 
>> Apache2/Apache/Filter.pm -
>> mp2 installs are expected to 'PerlModule Apache2' or somesuch if they 
>> want
>> their mp2 modules found.
> 
> 
> And just to be clear, IIUC, this means that if you don't have mod_perl1 
> installed, then Apache2 should *not* be appended to the pm_libs install 
> path, and using Apache2 in one's modules will have no affect.

That's correct. mp2-core knows whether it was installed into Apache2/ or not.


-- 
__________________________________________________________________
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: [Module::Build] Re: ModPerl::MB

Posted by Ken Williams <ke...@mathforum.org>.
On Dec 29, 2004, at 10:20 PM, David Wheeler wrote:

> I think, looking at the code, that all you need to do is override the 
> find_pm_files method like this:
>
>   sub find_pm_files {
>       my $files = shift->SUPER::find_pm_files;
>       for my $file (keys %$files) {
>           $files{$file} = File::Spec->catfile('Apache2', $file);
>       }
>       return $files;
>   }

Yup, that's right, except s/\$file\)/\$files{\$file}\)/.  Actually, it 
could just be:

   sub find_pm_files {
       my $files = shift->SUPER::find_pm_files;
       for my $file (values %$files) {
           $file = File::Spec->catfile('Apache2', $file);
       }
       return $files;
   }

except I think some versions of perl don't let you change hash values 
like that.

The stuff I showed was what you can do without subclassing M::B.  If 
you don't mind subclassing, then the above is the way to go.

  -Ken


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Module::Build] Re: ModPerl::MB

Posted by David Wheeler <da...@kineticode.com>.
On Dec 29, 2004, at 6:49 PM, Geoffrey Young wrote:

> for a bit of history here, what happens with mp2 is that if it sees a 
> mp1
> installation it installs everything under site_lib/Apache2/ (like
> Apache::Filter becomes Apache2/Apache/Filter.pm) as to not collide with
> existing modules in the mp1 namespace.  along with this is Apache2.pm, 
> which
> adjusts @INC so that Apache::Filter resolves to 
> Apache2/Apache/Filter.pm -
> mp2 installs are expected to 'PerlModule Apache2' or somesuch if they 
> want
> their mp2 modules found.

And just to be clear, IIUC, this means that if you don't have mod_perl1 
installed, then Apache2 should *not* be appended to the pm_libs install 
path, and using Apache2 in one's modules will have no affect.

On Dec 29, 2004, at 7:08 PM, Stas Bekman wrote:

> So there is no method to override that feeds the path like MM does? 
> The above requires manual search for the files, which is not something 
> we would like to do, on behalf of users, since it might go broken 
> (it's not under our control). It should be something like MM does, 
> where M::B already has the mapping and the override just manipulates 
> it.

I think, looking at the code, that all you need to do is override the 
find_pm_files method like this:

   sub find_pm_files {
       my $files = shift->SUPER::find_pm_files;
       for my $file (keys %$files) {
           $files{$file} = File::Spec->catfile('Apache2', $file);
       }
       return $files;
   }

But Ken can say for sure, I expect.

Regards,

David


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Module::Build] Re: ModPerl::MB

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
hi ken :)  many belated congrats on your new addition :)

Ken Williams wrote:
> 
> On Dec 29, 2004, at 8:22 PM, Stas Bekman wrote:
> 
>> with MM we override MY::constants so things end up in Apache2/ subdirs
>> in blib/. That's about it. so if normally a file would be installed
>> under /foo/bar it'll be now installed under /foo/bar/Apache2.
> 
> 
> Um, doesn't that really break things (like, say, perl) that are looking
> for modules in @INC and not map( "$_/Apache2", @INC)?

for a bit of history here, what happens with mp2 is that if it sees a mp1
installation it installs everything under site_lib/Apache2/ (like
Apache::Filter becomes Apache2/Apache/Filter.pm) as to not collide with
existing modules in the mp1 namespace.  along with this is Apache2.pm, which
adjusts @INC so that Apache::Filter resolves to Apache2/Apache/Filter.pm -
mp2 installs are expected to 'PerlModule Apache2' or somesuch if they want
their mp2 modules found.

for better or worse, this is the path that mp2 has chosen, and it really
doesn't make sense to rehash the virtue of that decision here - the mod_perl
list is doing a fine job of turning this into a little war all by itself.

however, what is important is for mp2 CPAN modules to be able to easily
follow the same paradigm that mod_perl core has chosen.  that is, say,
Apache::Clean for mp2 should install itself into Apache2/ if that's where
mp2 installed itself.  ModPerl::MM::WriteMakefile takes care of this for
MakeMaker-based modules.  David is wanting a similar utility for Module::Build.

anyway, I hope that makes sense and helps clarify things a bit.

--Geoff


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Module::Build] Re: ModPerl::MB

Posted by John Peacock <jp...@rowman.com>.
Stas Bekman wrote:
> Ken Williams wrote:
>> Um, doesn't that really break things (like, say, perl) that are 
>> looking for modules in @INC and not map( "$_/Apache2", @INC)?
> 
> Break what things? Any perl program that wants to find mp2 modules 
> starts with 'use Apache2' or -MApache2.

What Stas means is that the Apache2 version of Apache::Resources (which 
conflicts with the mp1 module by the same name) will be installed _as if_ it 
were actually called Apache2::Apache::Resources and can only be accessed by 
doing the magical 'use Apache2;' beforehand (which fixes up @INC to DTRT).

Doing this is a matter of inserting /Apache2/ before the actual name of the 
module before installing it in the normal site_perl/blah directories.

HTH

John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Module::Build] Re: ModPerl::MB

Posted by Stas Bekman <st...@stason.org>.
Ken Williams wrote:
> 
> On Dec 29, 2004, at 8:35 PM, Stas Bekman wrote:
> 
>> Ken Williams wrote:
>>
>>> On Dec 29, 2004, at 8:22 PM, Stas Bekman wrote:
>>>
>>>> with MM we override MY::constants so things end up in Apache2/ 
>>>> subdirs in blib/. That's about it. so if normally a file would be 
>>>> installed under /foo/bar it'll be now installed under /foo/bar/Apache2.
[...]
> You can provide a mapping from lib to blib in your Build.PL as follows:
> 
>  my $build = Module::Build->new
>    (
>     pm_files => {'lib/Apache/Foo.pm'             # as in MANIFEST
>                  => 'lib/Apache2/Apache/Foo.pm'  # as in blib/
>                  ...},
>     xs_files => {'lib/Apache/Foo.xs'             # as in MANIFEST
>                  => 'lib/Apache2/Apache/Foo.xs'  # as in blib/
>                  ...},
>     ... and so on
>    );
> 
> I think that ought to do the trick.

So there is no method to override that feeds the path like MM does? The 
above requires manual search for the files, which is not something we 
would like to do, on behalf of users, since it might go broken (it's not 
under our control). It should be something like MM does, where M::B 
already has the mapping and the override just manipulates it.


-- 
__________________________________________________________________
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: [Module::Build] Re: ModPerl::MB

Posted by Ken Williams <ke...@mathforum.org>.
On Dec 29, 2004, at 8:35 PM, Stas Bekman wrote:

> Ken Williams wrote:
>> On Dec 29, 2004, at 8:22 PM, Stas Bekman wrote:
>>> with MM we override MY::constants so things end up in Apache2/ 
>>> subdirs in blib/. That's about it. so if normally a file would be 
>>> installed under /foo/bar it'll be now installed under 
>>> /foo/bar/Apache2.
>> Um, doesn't that really break things (like, say, perl) that are 
>> looking for modules in @INC and not map( "$_/Apache2", @INC)?
>
> Break what things? Any perl program that wants to find mp2 modules 
> starts with 'use Apache2' or -MApache2.
>

That sure seems like a bad idea.  How many different contortions are 
you willing to go through in order to release mod_perl2 in the same 
namespaces as mod_perl, anyway?  It seems like about 89 million things 
would be easier if mod_perl2 lived in the Apache2 namespace (or the 
ModPerl namespace, or ...) and not the Apache namespace.

But I guess it's not what you were asking about, so I'll just answer 
your original question...

You can provide a mapping from lib to blib in your Build.PL as follows:

  my $build = Module::Build->new
    (
     pm_files => {'lib/Apache/Foo.pm'             # as in MANIFEST
                  => 'lib/Apache2/Apache/Foo.pm'  # as in blib/
                  ...},
     xs_files => {'lib/Apache/Foo.xs'             # as in MANIFEST
                  => 'lib/Apache2/Apache/Foo.xs'  # as in blib/
                  ...},
     ... and so on
    );

I think that ought to do the trick.

  -Ken


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Module::Build] Re: ModPerl::MB

Posted by Stas Bekman <st...@stason.org>.
Ken Williams wrote:
> 
> On Dec 29, 2004, at 8:22 PM, Stas Bekman wrote:
> 
>> with MM we override MY::constants so things end up in Apache2/ subdirs 
>> in blib/. That's about it. so if normally a file would be installed 
>> under /foo/bar it'll be now installed under /foo/bar/Apache2.
> 
> 
> Um, doesn't that really break things (like, say, perl) that are looking 
> for modules in @INC and not map( "$_/Apache2", @INC)?

Break what things? Any perl program that wants to find mp2 modules starts 
with 'use Apache2' or -MApache2.


-- 
__________________________________________________________________
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: [Module::Build] Re: ModPerl::MB

Posted by Ken Williams <ke...@mathforum.org>.
On Dec 29, 2004, at 8:22 PM, Stas Bekman wrote:
> with MM we override MY::constants so things end up in Apache2/ subdirs 
> in blib/. That's about it. so if normally a file would be installed 
> under /foo/bar it'll be now installed under /foo/bar/Apache2.

Um, doesn't that really break things (like, say, perl) that are looking 
for modules in @INC and not map( "$_/Apache2", @INC)?

  -Ken


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [Module::Build] Re: ModPerl::MB

Posted by Stas Bekman <st...@stason.org>.
Ken Williams wrote:
> 
> On Dec 29, 2004, at 2:12 PM, Stas Bekman wrote:
> 
>>
>> But M::B doesn't support XS yet, so that's moot.
> 
> 
> M::B has supported XS since it was in diapers.

Well, I've never used M::B, someone (?) said that it doesn't. If it does 
then great.

>> so David and I were only talking about ModPerl::MB subclass of M::B 
>> which will do the usual thing as any another non-mp2 module does, but 
>> will subclass whatever method it is to install mp2 modules under 
>> Apache2/ if mp2-core was installed there.
>>
>> so yes, as of this moment David description is the _whole_ point
> 
> 
> I'm not sure I understand - where is this Apache2/ directory?  Somewhere 
> local during the build, or the modules' final special resting place?

with MM we override MY::constants so things end up in Apache2/ subdirs in 
blib/. That's about it. so if normally a file would be installed under 
/foo/bar it'll be now installed under /foo/bar/Apache2.

> Maybe it's just a matter of adding the appropriate install_path entries 
> to the Module::Build constructor, which wouldn't even require a subclass.


-- 
__________________________________________________________________
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: [Module::Build] Re: ModPerl::MB

Posted by Ken Williams <ke...@mathforum.org>.
On Dec 29, 2004, at 2:12 PM, Stas Bekman wrote:
>
> But M::B doesn't support XS yet, so that's moot.

M::B has supported XS since it was in diapers.

>
> so David and I were only talking about ModPerl::MB subclass of M::B 
> which will do the usual thing as any another non-mp2 module does, but 
> will subclass whatever method it is to install mp2 modules under 
> Apache2/ if mp2-core was installed there.
>
> so yes, as of this moment David description is the _whole_ point

I'm not sure I understand - where is this Apache2/ directory?  
Somewhere local during the build, or the modules' final special resting 
place?

Maybe it's just a matter of adding the appropriate install_path entries 
to the Module::Build constructor, which wouldn't even require a 
subclass.

  -Ken


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: ModPerl::MB

Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>>From what I understand, the whole
>>point of that module is to detect when both mod_perl1 and mod_perl2 are
>>installed, and, when they are, to add "Apache" to the install path
>>before installing mod_perl2-specific modules.

That's Apache2/ (not Apache).

> well, that's not the _whole_ point :)  a mp1 Makefile.PL that needs to
> 
>   - interface with the mod_perl or apache C api via XS
>   - also compile on win32
> 
> looks something like this
> 
> http://www.modperlcookbook.org/code/ch03/Cookbook-SimpleRequest-0.01/Makefile.PL
> 
> note that even without the win32 foo mp1 still needs the call to
> Apache::src->new->inc to find the proper header files.

wo, wo, wo, nobody was even suggesting to do that for mp1. mp2 was the 
only one.

> for mp2, both of those features are taken care of automatically via
> ModPerl::MM::WriteMakefile. sure, it's a rare case but, as we've seen in just
> the last week, I'm not the only one that is writing XS extensions for mp2 :)

But M::B doesn't support XS yet, so that's moot.

so David and I were only talking about ModPerl::MB subclass of M::B which 
will do the usual thing as any another non-mp2 module does, but will 
subclass whatever method it is to install mp2 modules under Apache2/ if 
mp2-core was installed there.

so yes, as of this moment David description is the _whole_ point

-- 
__________________________________________________________________
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: ModPerl::MB

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> From what I understand, the whole
> point of that module is to detect when both mod_perl1 and mod_perl2 are
> installed, and, when they are, to add "Apache" to the install path
> before installing mod_perl2-specific modules.

well, that's not the _whole_ point :)  a mp1 Makefile.PL that needs to

  - interface with the mod_perl or apache C api via XS
  - also compile on win32

looks something like this

http://www.modperlcookbook.org/code/ch03/Cookbook-SimpleRequest-0.01/Makefile.PL

note that even without the win32 foo mp1 still needs the call to
Apache::src->new->inc to find the proper header files.

for mp2, both of those features are taken care of automatically via
ModPerl::MM:WriteMakefile. sure, it's a rare case but, as we've seen in just
the last week, I'm not the only one that is writing XS extensions for mp2 :)

anyway, this is kinda "just for the record" stuff - you guys are much better
suited to decide what and what not to support with Module::Build.

--Geoff

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org