apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr/build apr_common.m4
Date Tue, 27 Feb 2001 13:58:35 GMT
On Tue, Feb 27, 2001 at 07:45:18AM -0500, Jim Jagielski wrote:
> gstein@apache.org wrote:
>...
> >   * configure.in: just call APR_FLAG_HEADERS once. This allows autoconf to
> >     loop over the values *once* rather than substituting N loops for header
> >     checking. This drops configure's size from 340k down to 255k. (!!!)
>...
> That was on my list, but I was taking things slow. That's why I coded
> it the way I did ;)  Note that we'll be able to do the same with
> APR_FLAG_FUNCS as well, when it's appropriate.

Absolutely. APR_FLAG_FUNCS will need to have similar logic to what I did in
APR_FLAG_HEADERS. I just didn't care to go that far right now.

> The final tune, maybe, will be to avoid the actual call
> to AC_CHECK_HEADERS and hand-code it in, since AC_CHECK_HEADERS
> has it's own for/do loop, which we aren't using. There's a part
> of me that's hesitant about doing that... although it makes the
> configure script a bit uglier, it make it obvious how we are
> using AC_CHECK_HEADERS.

No way. There is zero advantage to doing that. We *are* using
AC_CHECK_HEADERS' for-loop, so I'm not sure what you're talking about.

The current code uses the for loop in the shell to do all the header
processing. Cache variables get set. We use M4 magic to check all the cache
variables and store results into the APR variables (e.g. "stdlibh"). The
only loop is in AC_CHECK_HEADERS. The M4 thing is an unrolled recursion over
a list, basically. Took me a long time to grok "the M4 way" and build that
macro, I tell ya :-)

Duplicating (read: "forking") AC_CHECK_HEADERS is a major mistake. What
happens when we upgrade autoconf? Lose any fixes? And to what benefit?

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message