Return-Path: 
 <dev-return-11122-apmail-apr-dev-archive=apr.apache.org@apr.apache.org>
Delivered-To: apmail-apr-dev-archive@www.apache.org
Received: (qmail 85837 invoked from network); 22 Feb 2004 20:59:00 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 22 Feb 2004 20:59:00 -0000
Received: (qmail 48887 invoked by uid 500); 22 Feb 2004 20:58:47 -0000
Delivered-To: apmail-apr-dev-archive@apr.apache.org
Received: (qmail 48853 invoked by uid 500); 22 Feb 2004 20:58:47 -0000
Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:dev@apr.apache.org>
List-Help: <mailto:dev-help@apr.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@apr.apache.org>
List-Subscribe: <mailto:dev-subscribe@apr.apache.org>
Delivered-To: mailing list dev@apr.apache.org
Received: (qmail 48840 invoked from network); 22 Feb 2004 20:58:47 -0000
Message-ID: <403917E3.7040802@attglobal.net>
Date: Sun, 22 Feb 2004 15:58:11 -0500
From: Jeff Trawick <trawick@attglobal.net>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020
X-Accept-Language: en-us, en
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> <20040222115004.C11984@lyra.org>
In-Reply-To: <20040222115004.C11984@lyra.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Symantec AntiVirus Scan Engine
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

Greg Stein wrote:
> On Sun, Feb 22, 2004 at 08:41:08AM -0500, Jeff Trawick 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)?
> 
> 
> Eh? I'm not sure that I understand this "brokenness" ... can you explain?

 > As I understand it, if a mix is needed, then we pull in the relevant unix
 > code with a .c file that simply does a #include. For example, see
 > file_io/os2/fullrw.c. I don't recall that we ever had a Makefile that
 > built code from *another* directory, so the only option was to use a
 > #include to pull that code in.

Maybe an include trick is needed when you get some files for a feature from the 
platform-specific directory and other files from the unix directory.

Example of a different situation: os390

This platform will use the atomic/os390 and dso/os390 directories but 
<feature>/unix for everything else.  The SUBDIRS variable in the top makefile 
caused the proper sub-make to be performed.

When you mentioned something recently about a problem with platforms (foggy 
memory) days, this is what I thought you meant.  I guess not :)