2012/2/19 Torsten Förtsch <torsten.foert...@gmx.net>: > 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 prefer this also. I'm not sure how to reconcile this in the Changes file for both modules though. We could add them to the tagged versions in svn and update the Changes file there, but then the exact files shipped with mod_perl and what is on CPAN won't match up for Makefile.PL. I could see this as being viewed as a bad practice, but since the change is to the Makefile.PL only, I think breaking the rules in this instance only is the pragmatic approach. > > 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
