Re: mod_perl 2.0 snapshot install issue
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
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
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
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
> 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
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