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
>
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 ();
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
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
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.
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
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 wa
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
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
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 ar
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 controlle
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 c
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
13 matches
Mail list logo
