Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Sender: trawick@bellsouth.net
To: dev@apr.apache.org
Subject: Re: cvs commit: apr/build apr_hints.m4
References: <20010601003550.95928.qmail@apache.org>
	<20010531184707.I9397@ebuilt.com>
	<m3snhk8e03.fsf@adsl-77-241-65.rdu.bellsouth.net>
	<15127.45171.352919.813247@critterling.garfield.home>
	<20010601134151.S23560@lyra.org>
	<m3y9rbn4af.fsf@adsl-77-241-65.rdu.bellsouth.net>
	<20010601223309.P23560@lyra.org>
From: Jeff Trawick <trawickj@bellsouth.net>
Date: 04 Jun 2001 07:44:40 -0400
In-Reply-To: <20010601223309.P23560@lyra.org>
Message-ID: <m366ecbhav.fsf@adsl-77-241-65.rdu.bellsouth.net>
Lines: 49
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Greg Stein <gstein@lyra.org> writes:

> On Fri, Jun 01, 2001 at 07:55:52PM -0400, Jeff Trawick wrote:
> > Greg Stein <gstein@lyra.org> writes:
> > 
> > > No. apr_hints is a last resort. Actual tests like the AC_TRY_COMPILE() that
> > > Justin did are the right way to do it. We should always try to avoid
> > > hard-coding conditions to the host/library/whatever and *test* for them
> > > instead.
> > > 
> > > autoconf was written to use the testing approach, rather than the "know
> > > everything about all platforms" approach that Apache 1.3 used. apr_hints is
> > > left over from the 1.3 days; ideally, we would find tests that would remove
> > > every single one of those hints.
> > 
> > Which of the text below do you disagree with?
> 
> I disagreed with the use of apr_hints, rather than tests. Your point about
> *timing* of those tests is entirely valid.

It seems to me that apr_hints is the only place where the timing is
correct. 

-------/-------

Assume we use the design where we use configure-time tests to
determine when we need to turn on libc feature test macros.

Consider that we have system A where in order to access some pthread
function we have to turn on a feature test macro and we have system B
where in order to access some networking function we have to turn on a
feature test macro.

For system A, we'll want to test for that pthread function before all
other configure-time tests so that we'll be using the same libc
feature test macros throughout.

For system B, we'll want to test for that networking function before
all other configure-time tests so that we'll be using the same libc
feature test macros throughout.

These constraints cannot be satisified unless we restart all tests
any time we add a libc feature test macro or we implement different
orders of tests for different platforms.

-- 
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...