Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <403A0BFC.2080304@attglobal.net>
Date: Mon, 23 Feb 2004 09:19:40 -0500
From: Jeff Trawick <trawick@attglobal.net>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: updated port of gen-build.py
References: <Pine.LNX.4.58.0402221230070.1462@eco.foo>
 <4038B174.3050603@attglobal.net> <Pine.LNX.4.58.0402221524180.1462@eco.foo>
In-Reply-To: <Pine.LNX.4.58.0402221524180.1462@eco.foo>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sascha Schumann wrote:
>>Should I assume that this is broken on the same platforms where
>>gen-build.py is broken (where a mix of unix and system-specific
>>code is used)?
> 
> 
>     The shell script uses similar logic, so I am afraid it might
>     have similar issues as well.  I suppose you refer to this
>     rule deciding which objects to compile:
> 
>     If a particular module (mmap, memory, etc) lacks a
>     platform-specific subdirectory, fall back to a generic
>     implementation (which happens to be unix all the time).
>     Compile all *.c files found in the selected subdirectory.

yep

actually, this issue seems to have been implemented in CVS very recently (blush!)

configure.in log shows:

Sat Feb 21 00:31:48 2004 UTC (2 days, 13 hours ago) by gstein

it looks like it builds the different OBJECTS_platform fine and hopefully picks 
the correct OBJECTS_platform to build

so this issue is fixed and shouldn't be a problem for the Python or the 
non-Python solution; sorry for not keeping up with things :(