perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fred Moyer <f...@redhotpenguin.com>
Subject Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2
Date Sun, 19 Feb 2012 18:34:01 GMT
2012/2/19 Fred Moyer <fred@redhotpenguin.com>:
> 2012/2/19 Torsten Förtsch <torsten.foertsch@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-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message