2012/2/19 Fred Moyer <f...@redhotpenguin.com>: > 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.
Adding a +1 to this plan. I have some reservations about this approach, but unless someone gives a -1 I think it is the best path. >> 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
