Re: mod_perl 2.0 snapshot install issue

2005-05-16 Thread jared
Here's what was returned.
# perl -le 'use ExtUtils::MakeMaker; print ExtUtils::MakeMaker->VERSION'
6.28
Thanks.
Jared
At 10:37 AM -0400 5/16/05, Stas Bekman wrote:
Jared Jackson wrote:
I was unable to install RC6 due to the version issue previously reported.
I downloaded the following snapshot:
modperl-2.0_20050515223638.tar.gz
and was able to successfully run "perl Makefile.PL"
But "make install" stops with the following error.
"make: *** No rule to make target `pm_to_blib.ts', needed by 
`glue_pods'.  Stop."
Jared, please post the output of:
perl -le 'use ExtUtils::MakeMaker; print ExtUtils::MakeMaker->VERSION'
--
__
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



Re: mod_perl 2.0 snapshot install issue

2005-05-16 Thread jared
Sorry about that. I was distracted for a moment with an urgent qmail issue.
Thanks for the help.
Jared
At 1:01 PM -0400 5/16/05, Stas Bekman wrote:
Jared, please do not take the thread off-list unless you were asked 
to. Thank you.

 Here is the code in my current snapshot of mod_perl (20050516104821).
 lib/ModPerl/BuildMM.pm
 require ExtUtils::MakeMaker;
 my $pm_to_blib = $ExtUtils::MakeMaker::VERSION >= 6.22
 ? "pm_to_blib.ts"
 : "pm_to_blib";
The fix was applied 5 weeks ago:
http://svn.apache.org/viewcvs.cgi/perl/modperl/trunk/lib/ModPerl/BuildMM.pm?rev=160304&r1=160126&r2=160304&diff_format=h
apparently the snapshots mechanism is broken /(giving you snapshots 
from January!), so I'll take care of it.

Meanwhile please try this version:
http://people.apache.org/~gozer/mp2/mod_perl-2.0.0-dev.tar.gz
"make: *** No rule to make target `pm_to_blib.ts', needed by 
`glue_pods'.  Stop."

--
__
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



MP2 output filters

2004-08-25 Thread Jared Cook
I am trying to implement a stream output filter and am having a little 
problem.  I need to have the INCLUDES filter process the output first 
and then send it to the mod_perl filter.  I used PerlSetOutputFilter 
INCLUDES, and I think it is getting the data before it goes to my filter. 

Now my problem:  It looks like every include that gets processed starts 
a new stream to my filter.  I need mod_include to process all the 
includes and THEN send the completed flat document to my mod_perl 
filter.  Is this possible?  Please advise.

TIA,
Jared
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


Building libapreq2 with bad with-apache2 switches

2004-09-11 Thread Jared Rhine
If I'm not mistaken, building libaqreq2 with both --with-apache2-apxs
and --with-apache2-src.  But you can do it and end up with an
almost-functional installation, or odd build errors (as I can recently
attest to).

Offered as consideration for an enhancement, it might be nice if
configure detected this condition and at least warned about possible
breakage, if not outright refuse to proceed.

-- [EMAIL PROTECTED]

"One cannot mark the point without marking the path."

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html



Re: [summary] The Conflict of mp1 vs mp2 vs mp22 vs ... vs mpNN

2005-01-10 Thread Jared Rhine
> Stas> 99.9% of users do *not* need to use this workaround. So that
> Stas> issue is moot if you ask me.

> Four out of my five biggest customers *will* need to have both
> modperl1 and modperl2 in the same Perl installation tree on their
> development machines, because they'll need to start looking at how to
> port their work over, and they won't want to duplicate-install all the
> other modules they use into two different Perl installations on one
> box.

I would like to support Randal's contention (if not his tone) that
indeed, in real-world mod_perl commercial situations that I'm familiar
with (say about 8), 80% of those real-world users will want to have both
mod_perl 1 and mod_perl 2 installed concurrently due to the
generally-accepted production practice of "if it ain't broke, don't fix
it".  By virtue of being actual mod_perl, they already have production
mp1 installations.  They will also want to be moving forward with
leading, new releases for development of new systems, that is, mp2.

In any case, Stas, I found myself frowning when you first put out that
"99.9% not a problem" number, and given the testaments given here, we
can at least say "everyone's just guessing" what the real number is.

Perhaps Randal should be thanking Stas for the potential conflicts, as
it's fair to say that consulting fees can increase from confusions and
complications arising from the mp1/mp2 transition.  I do believe it's
uncontested that with common configurations and proposals, simulataneous
mp1 and mp2 installations will not be straightforward.  People committed
to mod_perl system will muddle through without doubt.  New users won't
generally see issues regardless of which docs they read.  Though people
who say extra hurdles don't help the community much have a point.

On the gripping hand, I've never thought of mod_perl setup and
administration as very intuitive or inherently robust.  People who
figure it out at all are generally already a notch or two above  and have learned to read documentation.

As a result of mod_perl's multi-step setup, I've long been very careful
during new mod_perl setups.  For a number of years now, I've been using
private installation trees such that 0% of my commercial clients will
have any mp1/2 issues as they use private, snapshotted installation
trees to achieve high stability and service isolation.  My modern
installations if fact, generally use scripts which download, unpack,
build, and install private installations of Apache, mod_perl,
librequest, HTML::Mason, and even Perl itself with hundreds of modules
from CPAN installed, all into a self-contained directory tree.  Config
files, log/state files, and the docroot(s) go outside this tree.

Without revolutions in the mod_perl/Apache/CPAN space, this "private
installation" approach is one of the few likely to provide really
stable, isolated concurrent instances of mod_perl.  It should be noted
that mod_perl is not the only "application server" to suffer this
problem, and the same things should be done for python 2.x, the Java
multiverse, and PHP 4/5 web/SOA instances whenever availability,
isolation, maintainability, and testability matter.

Disk space is cheap.

For my part, I'd put forth that one acceptance criteria of whatever mp2
release approach is adopted should be "it should be hard to clobber an
existing installation by being careless with an mp2 installation".

Going forward, I'd ask the community to remain respectful, proposal and
evidence-focused, with an eye rough consensus and working code.  There
have been both shining examples and dismal failures thus far in the
discussion.



mod_perl 2.0 snapshot install issue

2005-05-15 Thread Jared Jackson
I was unable to install RC6 due to the version issue previously reported.
I downloaded the following snapshot:
modperl-2.0_20050515223638.tar.gz
and was able to successfully run "perl Makefile.PL"
But "make install" stops with the following error.
"make: *** No rule to make target `pm_to_blib.ts', needed by 
`glue_pods'.  Stop."


Here are the previous ten lines or so:
make[2]: Leaving directory `/downloads/modperl-2.0/xs/APR'
make[2]: Entering directory `/downloads/modperl-2.0/xs/Apache'
make[3]: Entering directory `/downloads/modperl-2.0/xs/Apache/Const'
make[3]: Leaving directory `/downloads/modperl-2.0/xs/Apache/Const'
make[2]: Leaving directory `/downloads/modperl-2.0/xs/Apache'
make[2]: Entering directory `/downloads/modperl-2.0/xs/ModPerl'
make[3]: Entering directory `/downloads/modperl-2.0/xs/ModPerl/Const'
make[3]: Leaving directory `/downloads/modperl-2.0/xs/ModPerl/Const'
make[2]: Leaving directory `/downloads/modperl-2.0/xs/ModPerl'
make[1]: Leaving directory `/downloads/modperl-2.0/xs'
This is perl, v5.8.5 built for i386-linux-thread-multi
Jared Jackson