>>>>> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
>> Why am I having this sense of deja vu? >> http://sc-archive.codesourcery.com/sc_config Russ> BuildConf is basically Autoconf plus Automake, which is useful Russ> but not what I want and which isn't going to be any easier to Russ> write probes in than Autoconf is now. It also brings in the Russ> whole build system problem, which is a different issue entirely. Is it really a different issue? I've often thought that it would be better to merge configury with the build -- that is, write a single new tool that replaces all of make, autoconf, libtool, and automake. I have a few reasons for wanting to merge the two processes. First, I don't think they are really separable. Some changes affect both the configuration and the build (e.g., add a probe for a function -- you'll change configure, config.h, and presumably some source files). I think we tend to think of these as different things, due to history, but that isn't the only model. Second, I think in many cases it would be more maintainable to have configury in the same files as the build. The current situation is less maintainable because some choices are made in configure.in and then used in Makefile.am, leading to a lot of to-and-fro reading when trying to figure out what is going on. Third, with parallel make on an SMP box, configure can start to dominate the build time -- an absurd situation. If configuration were integrated with the build, and probes expressed their dependencies, then configuration could be parallelized. Russ> Maybe the problem as I'm thinking of it is just too hard to Russ> really fully solve. I'm very curious to hear your ideas on how to express probes more clearly; the more specific the better. I've been thinking about this area a lot lately, but I've never considered that Autoconf's method for expressing tests might be a hindrance. Personally I've always found the quoting off-putting but bearable. Would it suffice to have a more reasonable programming language (say, Python/Perl/Ruby/Scheme/[insert your fave here], instead of m4+sh) with more reasonable quoting rules? Tom
