From dev-return-22474-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Mon Oct 19 14:00:59 2009 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 65253 invoked from network); 19 Oct 2009 14:00:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 19 Oct 2009 14:00:59 -0000 Received: (qmail 86268 invoked by uid 500); 19 Oct 2009 14:00:58 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 86174 invoked by uid 500); 19 Oct 2009 14:00:58 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 86166 invoked by uid 99); 19 Oct 2009 14:00:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Oct 2009 14:00:58 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.132.183.28] (HELO mx1.redhat.com) (209.132.183.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 Oct 2009 14:00:50 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n9JE0S5c006105 for ; Mon, 19 Oct 2009 10:00:29 -0400 Received: from fc11x64m0.jboss.hr (vpn-10-43.str.redhat.com [10.32.10.43]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id n9JE0RF0027110 for ; Mon, 19 Oct 2009 10:00:28 -0400 Message-ID: <4ADC70FB.8010305@apache.org> Date: Mon, 19 Oct 2009 16:00:27 +0200 From: Mladen Turk User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: dev@apr.apache.org Subject: Re: Mac OS X Universal builds and APR References: <7C3576B5-1E57-4E63-BAFC-3B0C3AFA50BF@jaguNET.com> <368F2942-58B7-4D14-ACF7-B23901522797@jaguNET.com> <4ADC0CF7.1010804@apache.org> <4ADC5905.1050000@apache.org> <4ADC66D5.4050700@apache.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.18 X-Virus-Checked: Checked by ClamAV on apache.org On 19/10/09 15:41, Jeff Trawick wrote: > > Perhaps I'm out in left field, but I anticipate that packagers will > determine the appropriate arch flags based on exactly what hardware > they support, and use that across a number of open source packages. Sure. > (Should "foo-32" support any 32-bit foo processor ever made, or just > those that could have been made in the last 10 years, or just those > supported by the level of the OS the packager prereqs, or ???) > I'm not saying this would satisfy each and every possibility just like config.layout doesn't. However, we have config.layout with some of the layouts that might even be different on the actual platform. We could have similar thing for arch options, that each packager could use as a template for the actual or specific target config. The point is that configure would offer an infrastructure for easy selection of those options in a same way one can append to the config.layout and use ./configure --enable-layout=foo Regards -- ^TM