Russ Allbery writes:
> Also note that Dan is reinventing parts of autoconf in his build process;
> that's what all those try programs are. He's doing precisely the same
> thing that autoconf does, namely write out a little program, compile it,
> and see what happens. So he's actually using precisely those "child's
> babblings" that you're dismissing, and using them in a similar way; he
> just hasn't surrounded them with m4 macros.
Well, Russ, I guess you've never been bitten by config.cache.
autoconf needs it because it's monolithic. Unix doesn't *do*
monolitic. Not Unix done right anyway. Take Dan's makefile for
instance. It's complicated, sure, but unlike the makefiles created by
autoconf, it's readable. And it's comprehensive. Change one thing,
and only those files that depend on it get rebuilt.
Sorry, Russ, but autoconf is a lose (compared to Dan's methods --
obviously it's much better than the old "edit the Makefile; edit
config.h; make; iterate" way). It's just wrong, all the way.
Something can solve a problem but still be the wrong solution.
--
-russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
