Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 41531 invoked by uid 500); 4 Jun 2003 18:23:57 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 41499 invoked from network); 4 Jun 2003 18:23:56 -0000 To: trawick@attglobal.net Subject: Re: cvs commit: apr/test testdso.c Message-ID: <1054751032.3ede39386b73d@www.xbc.nu> Date: Wed, 04 Jun 2003 20:23:52 +0200 (CEST) From: brane@xbc.nu Cc: dev@apr.apache.org References: <20030528182414.72461.qmail@icarus.apache.org> <3ED5F135.80706@attglobal.net> <20030529163602.GB26779@manyfish.co.uk> <3ED63BD2.9020605@attglobal.net> <3EDD1F45.4090402@xbc.nu> <3EDD21E2.40507@attglobal.net> In-Reply-To: <3EDD21E2.40507@attglobal.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 213.253.102.145 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Quoting Jeff Trawick : > Branko ��ibej wrote: > > > Imagine the mess if all APR users started to use APR_PLATFORM_IS_HPUX to > > decide the .so vs. .sl thing... this is exactly what APR is meant to avoid. > > Another factor is that not every portability issue affecting > applications that use APR is going to be adopted by APR as a problem > that it can or should solve. Some issues will always pop up for certain > apps, and whether or not APR provides a clean way to check the platform > isn't going to change that fact. So, what you're proposing is that APR provide mechanisms for people to write platform-specific code? That's in direct conflict with our mission to provice "predictable if not identical" behaviour across platforms. (It also seems a bit weird, but maybe that's just me... :-)