Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 90492 invoked from network); 20 Feb 2004 18:33:04 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 20 Feb 2004 18:33:04 -0000 Received: (qmail 25278 invoked by uid 500); 20 Feb 2004 18:32:48 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 25219 invoked by uid 500); 20 Feb 2004 18:32:48 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 25190 invoked from network); 20 Feb 2004 18:32:47 -0000 Received: from unknown (HELO suntzu.lyra.org) (198.144.203.208) by daedalus.apache.org with SMTP; 20 Feb 2004 18:32:47 -0000 Received: (from gstein@localhost) by suntzu.lyra.org (8.11.6/8.11.6) id i1KIasv32391; Fri, 20 Feb 2004 10:36:54 -0800 X-Authentication-Warning: suntzu.lyra.org: gstein set sender to gstein@lyra.org using -f Date: Fri, 20 Feb 2004 10:36:54 -0800 From: Greg Stein To: dev@httpd.apache.org, dev@apr.apache.org Subject: Re: apr/apr-util python dependence Message-ID: <20040220103654.C31755@lyra.org> Mail-Followup-To: dev@httpd.apache.org, dev@apr.apache.org References: <200402201810.i1KIA9n04160@devsys.jaguNET.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200402201810.i1KIA9n04160@devsys.jaguNET.com>; from jim@jaguNET.com on Fri, Feb 20, 2004 at 01:10:06PM -0500 X-URL: http://www.lyra.org/greg/ 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 On Fri, Feb 20, 2004 at 01:10:06PM -0500, Jim Jagielski wrote: > Ben Laurie wrote: > > > > Or even platforms you have heard of: within hours of this change I had > > complaints from people who couldn't build snapshots in order to try out > > mod_log_forensic... > > I hate to chime in here, but I must agree. Things have certainly > come a long way when the build/configure system tried to > be as LCD (lowest common denominator) as possible. And it was a recursive make solution which we're trying to fix. If you can come up with an LCD approach which has a single top-level Makefile, then please feel free. > If we require all this "extra" stuff, then, at least to my > mind, it means that we need to rethink not just patch. Oh, come on. For somebody building straight from CVS, to add a Python dependence? Okay, so it caught a few people unawares. We make changes like that all the time. But this one is not hard to solve. In any case, this whole notion of "rewrite as a shell script" just isn't going to fly. There is a lot more work that needs to happen, which I really can't see a shell script handling. As Joe Orton rightly pointed out, the build-outputs.mk output is *NOT* platform independent, yet it needs to be. We create one tarball and it goes to everybody, so that tarball (which includes build-outputs.mk) must be workable for everybody. Today, it encodes the platform of the person who generated the file. I just updated the script to generate output for all platforms (with the intent of the main Makefile selecting the right platform), but it isn't quite right. For example, it assumed that os2 wanted all the unix objects (in addition to the os2-specific objects), but that isn't right: it only wants SUBDIR/unix/ for when SUBDIR/os2/ is not specified. So I've got some logic to rework. Cheers, -g -- Greg Stein, http://www.lyra.org/