On Sunday, 19 February 2012 00:03:56 Steve Hay wrote:
> > Steve, could you please confirm that revision 1245946 works for you?
>
> I didn't commit because we're in the middle of making a release so I thought
> it wouldn't be appropriate without the RM's approval. Anyway, I like your
> patch better, and I can confirm that it works for me
Fine. So, I think the modperl side is now in proper shape.
> > The A::R Makefile.PL reads:
> > ...
> >
> > if ($ENV{MOD_PERL_2_BUILD}) {
> > push @ARGV, "-apxs $ENV{MP_APXS}";
> > my $mp_gen = satisfy_mp_generation(2);
> > }
> >
> > ...
> > So the string "-apxs ..." is pushed to @ARGV as a single argument. I
> > think that should rather read
> >
> >
> > push @ARGV, "-apxs", $ENV{MP_APXS};
>
> Yes, and hence we do indeed need to pass MP_APXS through in the environment,
> as you've now done in revision 1290839, plus I need to run "perl Makefile.PL
> MP_APXS=..." now (as per the INSTALL file!), rather than "perl Makefile.PL
> MP_AP_PREFIX=..." (as I've always done). I'm ok with that, but see later:
> Pushing two args onto @ARGV as you suggest works for me, but splicing them
> off again (splice @ARGV, -2) doesn't! It gives the error "Modification of
> non-creatable array value attempted", due to check_for_apache_test()
> calling Apache::TestMM::filter_args(), which actually assigns a new value
> to @ARGV (in my case, an empty array!). Given that @ARGV is getting
> rewritten anyway, I think it is simplest to not worry about trying pop the
> pushed values off again, so the attached patch simply deletes the pop
> lines.
Your patch looks fine to me.
How to proceed from here is a question we'd have to ask Fred. I see 3 options:
1) push out RC2 as is as 2.0.6
that would make Steve unhappy and we need another +1 in any case. The
reasoning for this solution is that the bug in A::R and A::SL sits there for
years and has survived several public releases. Two thirds of all of the SVN
commits came in after the one that introduced the bug.
2) commit Steve's changes to A::R and A::SL and roll another RC with them
Since these changes affect only the way modperl communicates MP_APXS to
bundled submodules at build time and nothing else one could argue to avoid the
overhead of creating 2 new releases and bundle the patched versions.
This is the option I'd prefer.
3) go the full circle: new releases of A::R and A::SL, then another modperl-RC
Further, it seems to me that MP_AP_PREFIX, MP_AP_DESTDIR, MP_APR_CONFIG and
MP_APR_LIB are all historical cruft and should be removed. Why do we need
dozens of ways to build modperl. The apxs command should know all the answers
of how to build and where to install modperl.
> > Another funny discovery I made in our top-level Makefile.PL. There is a
> > function named win32_fetch_apxs ...
>
> I didn't realize that the top-level Makefile.PL actually fetches apxs for
> you if you don't have it, but it seems worth leaving in if I understand
> things correctly:
>
> My understanding is that apxs is required for building modules likes
> mod_perl and libapreq and that it normally gets installed with Apache httpd
> but doesn't get installed on Win32, hence the existence of that separate
> apxs_win32.tar.gz package.
Yes, apxs is needed to answer questions like "Which C-compiler should be used
and which options it should be passed?" or "Where is the httpd binary
installed and where do modules go to?" or "Which httpd include files should be
used?" apxs can actually do a bit more. But such are the questions we ask it.
To answer them apxs here refers to a file share/build/config_vars.mk installed
with httpd. The absolute path of that file is hard-wired in apxs. So, apxs is
tightly bound to the httpd modperl is built for.
So, we have 2 options. We could either update the stuff at
http://perl.apache.org/dist/win32-bin and provide a working modern combination
of perl, httpd and modperl for win32 (and perhaps 64bit).
Or we could drop the stuff. Keeping it as is is a bit embarrassing, I feel.
> (I again haven't applied my patch myself because I'm not sure how to go
> about patching Reload and SizeLimit. I see they're downloaded into my
> mod_perl working copy as "externals", but can I commit changes from there?
I think you can
cd Apache-Reload && svn ci ...
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
