Return-Path: X-Original-To: apmail-perl-dev-archive@www.apache.org Delivered-To: apmail-perl-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3939A9679 for ; Sun, 19 Feb 2012 22:35:51 +0000 (UTC) Received: (qmail 76879 invoked by uid 500); 19 Feb 2012 22:35:51 -0000 Delivered-To: apmail-perl-dev-archive@perl.apache.org Received: (qmail 76846 invoked by uid 500); 19 Feb 2012 22:35:51 -0000 Mailing-List: contact dev-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@perl.apache.org Received: (qmail 76837 invoked by uid 99); 19 Feb 2012 22:35:51 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Feb 2012 22:35:51 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of SteveHay@planit.com designates 213.1.249.253 as permitted sender) Received: from [213.1.249.253] (HELO mailgate.planit.com) (213.1.249.253) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Feb 2012 22:35:46 +0000 Received: from mailgate.planit.com (localhost [127.0.0.1]) by mailgate.planit.com (Postfix) with ESMTP id 01C3443EC54; Sun, 19 Feb 2012 22:35:23 +0000 (GMT) X-Virus-Scanned: by SpamTitan at planit.com Received: from ukmail02.planit.group (ukmail02.planit.com [10.20.200.12]) by mailgate.planit.com (Postfix) with ESMTP id 667E543EC45; Sun, 19 Feb 2012 22:35:22 +0000 (GMT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCEF56.C3D42C16" Subject: RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 Date: Sun, 19 Feb 2012 22:35:21 -0000 Message-ID: <1B32FF956ABF414C9BCE5E487A1497E70C749E83@ukmail02.planit.group> In-Reply-To: <2216630.bdUjTcxAMf@opi.home> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2 Thread-Index: AczvM9DsUwKJygMDRXKp4mwabjEXCAAHrUCA References: <1438487.Q1GdrvHOSY@opi.home> <1B32FF956ABF414C9BCE5E487A1497E70C749E69@ukmail02.planit.group> <2216630.bdUjTcxAMf@opi.home> From: "Steve Hay" To: =?iso-8859-1?Q?Torsten_F=F6rtsch?= , Cc: "Fred Moyer" ------_=_NextPart_001_01CCEF56.C3D42C16 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Torsten F=F6rtsch wrote on 2012-02-19: > How to proceed from here is a question we'd have to ask Fred. I see 3 > options: >=20 > 1) push out RC2 as is as 2.0.6 >=20 > 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. >=20 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 >=20 > 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. >=20 > This is the option I'd prefer. >=20 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 >=20 >=20 > 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. >=20 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_Bui= ld_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 ... >>=20 >> 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: >>=20 >> 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. >=20 > 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. >=20 > 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). >=20 > 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! ------_=_NextPart_001_01CCEF56.C3D42C16 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC2

Torsten = F=F6rtsch 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.ht= ml#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/dis= t/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!

------_=_NextPart_001_01CCEF56.C3D42C16--