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!
