perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Hay" <Steve...@planit.com>
Subject RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2
Date Sun, 19 Feb 2012 22:35:21 GMT
Torsten Förtsch wrote on 2012-02-19:
> 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.
> 

Not so long ago (mod_perl-2.0.4) Apache-Reload wasn't bundled with mod_perl, so I had to install
it separately, and wasn't unhappy with needing to specify the -httpd option since it was a
separate installation.

But now that it's bundled, it ought to build and test correctly. In 2.0.5 the top-level Makefile
didn't run the A::R tests so I guess it got past me that it wasn't working, but now that the
top-level Makefile does run A::R's tests it's annoying for it not to work, so I wouldn't like
this option. (A::SL doesn't affect me at all since the winnt mpm is threaded anyway.)


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

I think that's the best solution too, not least since the state of A::R in RC2 seems a little
wonky anyway, claiming to be 0.11, but not including the last changed put into 0.11.


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

I wondered the same myself, but I'm not so sure now after looking at http://perl.apache.org/docs/2.0/user/install/install.html#Non_Boolean_Build_Options

They do each have a specific purpose, e.g. MP_AP_PREFIX can be useful when building against
httpd built in a source directory but not yet installed, MP_AP_DESTDIR is to assist package
maintainers, etc.

But it seems like MP_APXS is the best way to proceed when doing a normal build with an installed
httpd, and it is what the INSTALL file recommends, so my fixes to make MP_APXS work on Win32
are worthwhile.


>>> 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 agree that the Perl-5.8-win32-bin and perl-win32-bin packages are embarrassingly out of
date. I'm happy to upload new Apache+Perl+mod_perl packages as and when I build them for my
own use (normally for each new 5.X.0 release of perl, and for each new release of mod_perl,
with whatever Apache httpd is current at the time) if that would be useful, or we can simply
drop them altogether.

But the apxs_win32 package has to stay since there is no other apxs that I know of for Win32!

Mime
View raw message