Re: [patch + rfc] installing modperl .h files
On Fri, 2003-01-31 at 12:53, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > On Thu, 2003-01-30 at 12:32, Stas Bekman wrote:
> >
> >>The attached patch (because it has \t embedded) enables the installation of
> >>src/modules/perl/*.h and xs/*.h files, because we need them to be installed
> >>for XS extensions to be built.
> >
> >
> > +1 Great!
> >
> >
> >>First of all I'm not sure if that's the right way to install these, but it
> >>works for me.
> >>
> >>Second, I've chosen to install them to $APACHE_INSTALL_DIR/include in parallel
> >>with $APACHE_INSTALL_DIR/modules where we install mod_perl.so to. Is this a
> >>good choice, or do we want to install it under the perl lib tree as in
> >>mod_perl 1.0?
> >
> >
> > I would rather see it installed in the perl tree, just like in 1.0.
>
> I'm +0 on any place, it just was easier for me to implement it that way ;)
>
> >>Me thinking that it's nice to have all the headers in the same
> >>location (we have the ap_ and apr_ headers there already) and we don't need to
> >>mess with Apache2 prefixes here. The potential drawback that I could see is
> >>the various packaging approaches which will have to know where apache is
> >>installed.
> >
> >
> > That, and what if apache is upgraded/reinstalled and the content of the
> > destination include directory is whiped+reinstalled ?
>
> You still need to have to install mod_perl.so there (don't have to, but that's
> where we currently install to), so if you reinstall things by removing the
> apache tree, you have to reinstall mod_perl anyways.
Well, in my case, I always do
$> perl Makefile.PL PREFIX=$BASE/mod_perl/1.27/
For example. That way all mod_perl stuff is in its own directory. Not in
the perl tree, not in the apache tree (except for libperl.so).
But I seriously have no idea what's the most common thing for users to
do.
> Perhaps mod_perl.so should be installed under the perl tree as well. Don't
> know if it's a good idea.
If anywhere, I think mod_perl.is better of in apache_dir.
> __
> Stas BekmanJAm_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]
>
>
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5
(122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107
88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so
ingenious.
perl
-e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: using ModPerl::MM as a replacement for Apache::src
Stas Bekman wrote: Doug, have you intended ModPerl::MM to be used only internally to the mod_perl build or by other 3rd party modules as well? I like it much more than Apache::src. I'm currently porting Apache::Peek and the Makefile.PL is: use Apache2; use mod_perl 1.99; use ModPerl::MM (); ModPerl::MM::WriteMakefile( NAME => "Apache::Peek", VERSION_FROM => "Peek.pm", ); And it works ;) however you do it, it would be nice if all platforms had the same level of ease as unix - namely Win32. Randy did some nice work on creating a Makefile.PL template that works on both Win32 and Unices, but it's rather verbose and relies on Apache::src. see http://www.modperlcookbook.org/code/ch03/Cookbook-SimpleRequest-0.01/Makefile.PL for an example. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: public mod_perl 2.0 C API
Stas Bekman wrote: As I was exposing mpxs_Apache_request as I needed it in Apache::Peek, I was thinking what is the public C mod_perl API. Is that everything that is defined in mod_?perl.*\.h and modperl_xs.*\.h files? What about the XS extensions, if a 3rd party app wants to use a C function which is not in the core, but in an XS extension, how does it get to that header file? Most of those things are autogenerated with static functions, so the header file is of no use. hmmm... over in 1.0 land, there are a few XS macros in mod_perl_xs.h that are of use. in 2.0, there's the C function sv_str_header that I needed to add in order to iterate with apr_table_do, which others may find useful as well. In general, I'd think that the majority of the C and XS stuff would be private, with only a few really useful mod_perl functions - most of the stuff mod_perl hackers would want is probably ap_* stuff, plus the XS macros that make life easier. how to design it... I dunno :) --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch + rfc] installing modperl .h files
Philippe M. Chiasson wrote: [...] Me thinking that it's nice to have all the headers in the same location (we have the ap_ and apr_ headers there already) and we don't need to mess with Apache2 prefixes here. The potential drawback that I could see is the various packaging approaches which will have to know where apache is installed. That, and what if apache is upgraded/reinstalled and the content of the destination include directory is whiped+reinstalled ? You still need to have to install mod_perl.so there (don't have to, but that's where we currently install to), so if you reinstall things by removing the apache tree, you have to reinstall mod_perl anyways. Well, in my case, I always do $> perl Makefile.PL PREFIX=$BASE/mod_perl/1.27/ For example. That way all mod_perl stuff is in its own directory. Not in the perl tree, not in the apache tree (except for libperl.so). But I seriously have no idea what's the most common thing for users to do. Perhaps mod_perl.so should be installed under the perl tree as well. Don't know if it's a good idea. If anywhere, I think mod_perl.is better of in apache_dir. In any case, if we install the headers under the perl tree, shouldn't we copy the apache headers there as well? Perhaps Doug will pop up... __ Stas BekmanJAm_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]
Re: using ModPerl::MM as a replacement for Apache::src
Geoffrey Young wrote: Stas Bekman wrote: Doug, have you intended ModPerl::MM to be used only internally to the mod_perl build or by other 3rd party modules as well? I like it much more than Apache::src. I'm currently porting Apache::Peek and the Makefile.PL is: use Apache2; use mod_perl 1.99; use ModPerl::MM (); ModPerl::MM::WriteMakefile( NAME => "Apache::Peek", VERSION_FROM => "Peek.pm", ); And it works ;) however you do it, it would be nice if all platforms had the same level of ease as unix - namely Win32. Randy did some nice work on creating a Makefile.PL template that works on both Win32 and Unices, but it's rather verbose and relies on Apache::src. see http://www.modperlcookbook.org/code/ch03/Cookbook-SimpleRequest-0.01/Makefile.PL for an example. Thanks Geoff, don't forget that ModPerl::MM::WriteMakefile is *already* used to build mod_perl extensions on Win32. So I don't think there should be any problem. It's definitely a good idea to hide all those platform specific things for the end-developers. __ Stas BekmanJAm_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]
CPAN.pm and UNINST=1 for 2.0 and other problems.
I've UNINST=1 set in my CPAN/Config.pm, so that older versions will be automatically cleaned up. Now that means if I install mod_perl 2.0 or any 3rd party 2.0 modules, the 1.0 version will get uninstalled. In case of mod_perl 1.0, it'll be uninstalled only partially (since it uninstalls only the same filenames that it's installing). Another problem with CPAN is that it would be impossible to upgrade 1.0 modules, if the corresponding 2.0 versions will be on CPAN :( __ Stas BekmanJAm_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]
defining a common API to build modules for 2.0
I'm porting Apache::Peek to 2.0 (which is pretty much done, but relies on
various patches to the mod_perl core, which aren't in).
The final distribution package will work with 1.0 and 2.0. At the build time
it has to know for which mod_perl we are building it. It'd be nice to devise a
common way to do this choice for all 3rd party module writers and even have
mod_perl 2.0 provide an API for that.
Currently I do:
Makefile.PL:
[...]
my %args = map {split /=/, $_ } @ARGV;
if ($ENV{MOD_PERL2} || $args{MOD_PERL2}) {
#warn "Looking for mod_perl 2.0";
require Apache2;
require mod_perl;
if ($mod_perl::VERSION < 1.99) {
die "You don't seem to have mod_perl 2.0 installed";
}
$mp_version = 2;
} else {
require mod_perl;
$mp_version = 1;
}
[...]
-
so if you run:
perl Makefile.PL MOD_PERL2=1
or have an env var MOD_PERL2=1 set the 2.0 version will be attempted to be built.
If we all use the same convention, a user can define the env var and than
things like CPAN.pm will work automatically.
So the above code could be wrapped into an API, which will return the version
it should build for and a new version will look like:
Makefile.PL
my $mp_version = ModPerl::MM::build_version();
I don't know whether to require to pass @ARGV. we could make it receive an
optional string.
Further build_version() can be smarter and check for both mod_perl versions.
And then ask the user which one he wants to use if both present.
The bummer is that 1.0 won't have ModPerl::MM::build_version, but this can be
remedied by releasing it on CPAN.
We can go further and write the whole module that will perform WriteMakefile
as well for 1.0 and 2.0 transparently for the user and include it in 2.0 and
on CPAN for 1.0 users.
The only drawback is that CPAN.pm won't be able to pick it up automatically,
since it needs to be installed before WriteMakefile is called.
__
Stas BekmanJAm_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]
Re: CPAN.pm and UNINST=1 for 2.0 and other problems.
On Sat, 1 Feb 2003, Stas Bekman wrote: > I've UNINST=1 set in my CPAN/Config.pm, so that older versions > will be automatically cleaned up. Now that means if I install > mod_perl 2.0 or any 3rd party 2.0 modules, the 1.0 version will > get uninstalled. In case of mod_perl 1.0, it'll be uninstalled > only partially (since it uninstalls only the same filenames > that it's installing). > > Another problem with CPAN is that it would be impossible to > upgrade 1.0 modules, if the corresponding 2.0 versions will be > on CPAN :( I'm not sure about this problem for mod_perl itself, but perhaps one way to address the problem of 3rd party modules (with both mod_perl 1 and 2 versions) is for authors to distribute the modules in the same distribution and then adopt a convention to arrange for the mod_perl 2.0 modules to be placed under Apache2/. The user can then (interactively) install either one (or both) versions without affecting the other (I'm not sure about this for modules with xs components, though). However, for CPAN.pm, 'use Apache2' wouldn't normally be done so as to adjust @INC to see the installed Apache2 modules. Perhaps PERL5LIB would have to be set by the user, which isn't great - if it was a simple thing, perhaps Andreas might include such a functionality in CPAN.pm. Another thing, as you mentioned, is the version numbering used by CPAN.pm to recommend upgrades. Assuming the module name is the same for both mod_perl 1 and 2 versions, what might work, if the author has both versions in the same package, is for the mod_perl 1 and 2 version numbers to be synched when an update is made. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CPAN.pm and UNINST=1 for 2.0 and other problems.
Randy Kobes wrote:
On Sat, 1 Feb 2003, Stas Bekman wrote:
I've UNINST=1 set in my CPAN/Config.pm, so that older versions
will be automatically cleaned up. Now that means if I install
mod_perl 2.0 or any 3rd party 2.0 modules, the 1.0 version will
get uninstalled. In case of mod_perl 1.0, it'll be uninstalled
only partially (since it uninstalls only the same filenames
that it's installing).
Another problem with CPAN is that it would be impossible to
upgrade 1.0 modules, if the corresponding 2.0 versions will be
on CPAN :(
I'm not sure about this problem for mod_perl itself, but perhaps
one way to address the problem of 3rd party modules (with both
mod_perl 1 and 2 versions) is for authors to distribute the
modules in the same distribution and then adopt a convention to
arrange for the mod_perl 2.0 modules to be placed under Apache2/.
The user can then (interactively) install either one (or both)
You know that interactive installs are best avoided if possible. If we do it
right, only for the build of mod_perl from CPAN you'd need to tell where apxs
or the includes dir is, which I think can be controlled from the env vars as well.
versions without affecting the other (I'm not sure about this for
modules with xs components, though).
That's where ModPerl::MM::WriteMakefile kicks in, it will handle all this
automatically.
I can't test whether installing mod_perl 2.0 will delete 1.0 with UNINST=1,
because CPAN doesn't index non-released modules ('_' in the version).
However, for CPAN.pm, 'use Apache2' wouldn't normally be done so
as to adjust @INC to see the installed Apache2 modules. Perhaps
PERL5LIB would have to be set by the user, which isn't great - if
it was a simple thing, perhaps Andreas might include such a
functionality in CPAN.pm.
No, no, Makefile.PL of the module should do it by itself. (See my other email,
I've posted after this one). I think the env var should do the trick. you can
even create convenient aliases for this, if you don't want to set things
globally. So whenever you want to use CPAN for mod_perl 1.0 you'd call:
alias cpan-mp1 perl -MCPAN -eshell
and for 2.0 you'd have:
alias cpan-mp2 MOD_PERL2=1 perl -MCPAN -eshell
That's why I was talking about using a common way to tell Makefile.PL what
version we are building for. If we (3rd party module developers) all confirm
to it, than things will be really easy.
Another thing, as you mentioned, is the
version numbering used by CPAN.pm to recommend upgrades. Assuming
the module name is the same for both mod_perl 1 and 2 versions,
what might work, if the author has both versions in the same
package, is for the mod_perl 1 and 2 version numbers to be
synched when an update is made.
That should work. The only drawback is the following: Let's say you've a
stable version of your module for 1.0, but you do lost of new releases for
2.0. If you have a unified version number for 1.0 and 2.0, 1.0 users will be
prompted to update their module even though nothing has changed for 1.0.
__
Stas BekmanJAm_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]
Re: defining a common API to build modules for 2.0
On Sat, 1 Feb 2003, Stas Bekman wrote:
> I'm porting Apache::Peek to 2.0 (which is pretty much done, but
> relies on various patches to the mod_perl core, which aren't
> in).
>
> The final distribution package will work with 1.0 and 2.0. At
> the build time it has to know for which mod_perl we are
> building it. It'd be nice to devise a common way to do this
> choice for all 3rd party module writers and even have mod_perl
> 2.0 provide an API for that.
>
> Currently I do:
>
> Makefile.PL:
>
> [...]
> my %args = map {split /=/, $_ } @ARGV;
> if ($ENV{MOD_PERL2} || $args{MOD_PERL2}) {
> #warn "Looking for mod_perl 2.0";
> require Apache2;
> require mod_perl;
> if ($mod_perl::VERSION < 1.99) {
> die "You don't seem to have mod_perl 2.0 installed";
> }
> $mp_version = 2;
> } else {
> require mod_perl;
> $mp_version = 1;
> }
> [...]
> -
>
> so if you run:
>
>perl Makefile.PL MOD_PERL2=1
>
> or have an env var MOD_PERL2=1 set the 2.0 version will be
> attempted to be built.
>
> If we all use the same convention, a user can define the env
> var and than things like CPAN.pm will work automatically.
>
> So the above code could be wrapped into an API, which will
> return the version it should build for and a new version will
> look like:
>
> Makefile.PL
>
> my $mp_version = ModPerl::MM::build_version();
>
> I don't know whether to require to pass @ARGV. we could make it
> receive an optional string.
>
> Further build_version() can be smarter and check for both
> mod_perl versions. And then ask the user which one he wants to
> use if both present.
>
> The bummer is that 1.0 won't have ModPerl::MM::build_version,
> but this can be remedied by releasing it on CPAN.
>
> We can go further and write the whole module that will perform
> WriteMakefile as well for 1.0 and 2.0 transparently for the
> user and include it in 2.0 and on CPAN for 1.0 users.
>
> The only drawback is that CPAN.pm won't be able to pick it up
> automatically, since it needs to be installed before
> WriteMakefile is called.
This sounds like a great idea, having it in a module like this
... Until that occurs, and becomes available on CPAN, perhaps
something that could be done is having an h2xs-ish tool that
would provide a template authors could use to, in particular,
have a function to detect the mod_perl version right in
Makefile.PL.
Another thing that might be considered is to have a convention
where mod_perl 2 versions are installed under Apache2/, with
mod_perl 1 verions under Apache/. I did this for Apache-GeoIP -
what happens there is, when the mod_perl version is decided, the
appropriate files in the distribution under Apache2/ or Apache/
(corresponding to mod_perl 2 and 1 versions), are then copied to
a lib/ directory, and MakeMaker takes care of the rest.
--
best regards,
randy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: CPAN.pm and UNINST=1 for 2.0 and other problems.
On Sat, 1 Feb 2003, Stas Bekman wrote: > On Sat, 1 Feb 2003, Randy Kobes wrote: > You know that interactive installs are best avoided if > possible. If we do it right, only for the build of mod_perl > from CPAN you'd need to tell where apxs or the includes dir is, > which I think can be controlled from the env vars as well. That's true - I was thinking of cases where both versions are available, but this can be done thru environment variables. > > However, for CPAN.pm, 'use Apache2' wouldn't normally be done so > > as to adjust @INC to see the installed Apache2 modules. Perhaps > > PERL5LIB would have to be set by the user, which isn't great - if > > it was a simple thing, perhaps Andreas might include such a > > functionality in CPAN.pm. > > No, no, Makefile.PL of the module should do it by itself. (See > my other email, I've posted after this one). I think the env > var should do the trick. you can even create convenient aliases > for this, if you don't want to set things globally. So whenever > you want to use CPAN for mod_perl 1.0 you'd call: > > alias cpan-mp1 perl -MCPAN -eshell > > and for 2.0 you'd have: > > alias cpan-mp2 MOD_PERL2=1 perl -MCPAN -eshell > > That's why I was talking about using a common way to tell > Makefile.PL what version we are building for. If we (3rd party > module developers) all confirm to it, than things will be > really easy. That's true ... What I was thinking about PERL5LIB was that CPAN.pm, when looking for installed modules, won't normally search under Apache2/, and thus won't be able to recommend upgrades if available. That again could be handled via environment variables (PERL5LIB, and MOD_PERL2 or MOD_PERL1), and calling the CPAN.pm shell appropriately, as you say. > > > Another thing, as you mentioned, is the > > version numbering used by CPAN.pm to recommend upgrades. Assuming > > the module name is the same for both mod_perl 1 and 2 versions, > > what might work, if the author has both versions in the same > > package, is for the mod_perl 1 and 2 version numbers to be > > synched when an update is made. > > That should work. The only drawback is the following: Let's say > you've a stable version of your module for 1.0, but you do lost > of new releases for 2.0. If you have a unified version number > for 1.0 and 2.0, 1.0 users will be prompted to update their > module even though nothing has changed for 1.0. That is a drawback ... Specifying MOD_PERL1 or MOD_PERL2 would at least specify which version to install ... -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CPAN.pm and UNINST=1 for 2.0 and other problems.
Randy Kobes wrote: On Sat, 1 Feb 2003, Stas Bekman wrote: On Sat, 1 Feb 2003, Randy Kobes wrote: You know that interactive installs are best avoided if possible. If we do it right, only for the build of mod_perl from CPAN you'd need to tell where apxs or the includes dir is, which I think can be controlled from the env vars as well. That's true - I was thinking of cases where both versions are available, but this can be done thru environment variables. I think the logic should be: - If only one version is available go straight for it. - If there are both: - If MOD_PERL2=1 is set, go for it - otherwise prompt user However, for CPAN.pm, 'use Apache2' wouldn't normally be done so as to adjust @INC to see the installed Apache2 modules. Perhaps PERL5LIB would have to be set by the user, which isn't great - if it was a simple thing, perhaps Andreas might include such a functionality in CPAN.pm. No, no, Makefile.PL of the module should do it by itself. (See my other email, I've posted after this one). I think the env var should do the trick. you can even create convenient aliases for this, if you don't want to set things globally. So whenever you want to use CPAN for mod_perl 1.0 you'd call: alias cpan-mp1 perl -MCPAN -eshell and for 2.0 you'd have: alias cpan-mp2 MOD_PERL2=1 perl -MCPAN -eshell That's why I was talking about using a common way to tell Makefile.PL what version we are building for. If we (3rd party module developers) all confirm to it, than things will be really easy. That's true ... What I was thinking about PERL5LIB was that CPAN.pm, when looking for installed modules, won't normally search under Apache2/, and thus won't be able to recommend upgrades if available. That again could be handled via environment variables (PERL5LIB, and MOD_PERL2 or MOD_PERL1), and calling the CPAN.pm shell appropriately, as you say. True, perl -MApache2 -MCPAN -eshell should be sufficient. PERL5LIB is going to be too messed up to explain to other people, because of the arch-platform-multi-ithreads thingies ;) Another thing, as you mentioned, is the version numbering used by CPAN.pm to recommend upgrades. Assuming the module name is the same for both mod_perl 1 and 2 versions, what might work, if the author has both versions in the same package, is for the mod_perl 1 and 2 version numbers to be synched when an update is made. That should work. The only drawback is the following: Let's say you've a stable version of your module for 1.0, but you do lost of new releases for 2.0. If you have a unified version number for 1.0 and 2.0, 1.0 users will be prompted to update their module even though nothing has changed for 1.0. That is a drawback ... Specifying MOD_PERL1 or MOD_PERL2 would at least specify which version to install ... Yes, but 'r' will suggest an update, which should lead to an update of whatever you've configured. __ Stas BekmanJAm_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]
Re: defining a common API to build modules for 2.0
Randy Kobes wrote: [...] This sounds like a great idea, having it in a module like this ... Until that occurs, and becomes available on CPAN, perhaps something that could be done is having an h2xs-ish tool that would provide a template authors could use to, in particular, have a function to detect the mod_perl version right in Makefile.PL. As soon as we define how it should work it can be on CPAN. Then authors can choose to use that module or if they prefer to have a full control that module is already the template that you are talking about. But I'd try to have all authors using that module if possible. So if things change internally, 1.0 users need to update that module 2.0 users will get it automatically and module authors won't need to touch their modules. Another thing that might be considered is to have a convention where mod_perl 2 versions are installed under Apache2/, with mod_perl 1 verions under Apache/. I did this for Apache-GeoIP - what happens there is, when the mod_perl version is decided, the appropriate files in the distribution under Apache2/ or Apache/ (corresponding to mod_perl 2 and 1 versions), are then copied to a lib/ directory, and MakeMaker takes care of the rest. Are you talking about the source distribution? I've tried the following approach. mp1/Makefile.PL.in mp2/Makefile.PL.in now the function that we are discussing returns you 1 or 2, next the top Makefile.PL does: cp mp1/Makefile.PL.in mp1/Makefile.PL and runs WriteMakefile(), which descends only to the dir with Makefile.PL. But it's really up to the author how to handle that. I've first tried this approach with Apache::Peek, but I've to handle 5 different combination, and I decided to go with files to avoid maintaining duplicates, so currently the distribution is: Makefile.PL MANIFEST Peek.pm.mp1.perl5.5 Peek.pm.mp1.perl5.6 Peek.pm.mp1.perl5.8 Peek.pm.mp2.perl5.6 Peek.pm.mp2.perl5.8 Peek.xs.mp1.perl5.5 Peek.xs.mp1.perl5.6 Peek.xs.mp1.perl5.8 Peek.xs.mp2.perl5.6 Peek.xs.mp2.perl5.8 ppport.h README test.pl Makefile.PL decides on the perl and mp versions and then creates the appropriate .pm and .xs files by copying them and glueing the pod to .pm. So it's all depends on the complexity of your source distribution. That's said, we could certain provide convenience wrappers to handle both: the pick-dir and pick-files approach. __ Stas BekmanJAm_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]
