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> <20010601164509.X9397@ebuilt.com>
From: Jeff Trawick <trawickj@bellsouth.net>
Date: 01 Jun 2001 20:01:06 -0400
In-Reply-To: <20010601164509.X9397@ebuilt.com>
Message-ID: <m3itifkawt.fsf@adsl-77-241-65.rdu.bellsouth.net>
Lines: 26
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Justin Erenkrantz <jerenkrantz@ebuilt.com> 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.
> 
> Since the thread tests are the first real tests performed by APR's
> autoconf - any additional CPPFLAGS (or whatnot) will get passed to
> all subsequent tests.  I think this is Jeff's concern (perfectly 
> valid - I have it too).
> 
> Looking at configure,in, I don't think we could move the threading 
> tests around too much.  It looks like it is in the right place.  
> -- justin

So for this particular test on this particular platform we're fine.

Later, for some other platform we find that we need to test for
feature foo before we test for threads because feature foo is where we
figure out that we must enable some libc feature test macro.

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