On Tue, Feb 27, 2001 at 07:45:18AM -0500, Jim Jagielski wrote: > [EMAIL PROTECTED] 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/
