Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <485C3166.7010003@apache.org>
Date: Sat, 21 Jun 2008 00:38:30 +0200
From: Ruediger Pluem <rpluem@apache.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: svn commit: r669920 - /httpd/httpd/branches/2.2.x/configure.in
References: <20080620144923.019462388A51@eris.apache.org>
 <485C1E27.8030109@apache.org> <485C2A1E.7050106@rowe-clan.net>
In-Reply-To: <485C2A1E.7050106@rowe-clan.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


On 06/21/2008 12:07 AM, William A. Rowe, Jr. wrote:
> Ruediger Pluem wrote:
>>
>> On 06/20/2008 04:49 PM, wrowe@apache.org wrote:
>>> Author: wrowe
>>> Date: Fri Jun 20 07:49:22 2008
>>> New Revision: 669920
>>>
>>> URL: http://svn.apache.org/viewvc?rev=669920&view=rev
>>> Log:
>>> AC_USE_SYSTEM_EXTENSIONS encompases _MINIX and _AIX and
>>> silences autoconf 2.62
>>>
>>> Modified:
>>>     httpd/httpd/branches/2.2.x/configure.in
>>
>> Sorry for being confused, but why are these changes not RTC?
> 
> They can be, if you like.  I'm not fond of discovering that the build
> against a --with-ssl= path blows up completely once you salt it with
> zlib compression (kerberos, resolv etc) on platforms with satisfy all
> symbols in effect.  Worked quite nicely back in my good old days of
> openssl 0.9.7, and I then discovered nobody considered actually fixing
> our stable branch with the corrections on trunk.
> 
> Of course it picked up pkg-config testing of the wrong openssl.pc at
> the wrong place in the configure script, and my rage at the build
> system proceeded from there.  If a necessary patch can sit back for
> 2.5 years, that's a problem.

I agree that this is a problem, but I think this is not specific to
autoconf issues. Some patches once committed to trunk are simply forgotten,
I am guilty of this by myself sometimes.
But this as such has nothing to do with RTC / CTR.

> 
> In short, it's fallen into disrepair.  At this point only one flaw
> remains, and that's the nested pcre crying out during ./buildconf.
> Even looked for a switch option to silence it, but autoheader won't
> agree to shut up.

AFAIK this has been there forever. If you find a way to fix it I will
miss something when executing buildconf :-).

> 
> So I treated this set of changes as build schema changes as I would
> on Win32, where people equally ignore how the schema will impact any
> build except their own.  But if someone with more Autoconf-foo than I(*)
> would like to actually challenge the changes, or find a single flaw,
> I'm all set to be beaten up over them.  Fire away(**).

I don't doubt your autoconf knowledge, but I think we should have and actually
have enough people around who should be able to review these changes (e.g. Joe)
on trunk and later on for backport. WIN32 is IMHO a different beast.
At least for sometime, at least this was my gut feeling, you were the only
person around to understand the changes needed to the windows build system
to make things work. So votes on backports would have been pointless.
I think Tom's addition to the committer roster should improve this
a litte bit as more eyes on changes are better, because even the most
genius guy makes errors from time to time.

> 
> Bill
> 
> 
> (*) clear from a number of issues that autoconf patches are not reviewed
>     by any httpd'ers, autoconf is simply bludgeoned into submission

I admit that at least sometimes I am guilty of this as well. But I will try
to improve in the future.

> 
> 
> (**) yes, I'm grumpy today
> 
> 

I hope my answer considered this enough :-).
BTW: Thanks for taking care of the issue.

Regards

Rüdiger