Tom Tromey <[EMAIL PROTECTED]> writes: > 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).
Well, that doesn't really change both the configuration and the build; that just changes the configuration and some source files. Normally, when I modify configure.in, I don't have to change makefiles at all, just the source code. (Or I only modify makefiles, not the source.) That being said, I think there are definite advantages to integrating the dependencies of the probes and the running of the probes with the rest of the build for the reasons you describe below, namely parallelization. > 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. Hm, yeah, there's something to be said for that. Well, I think we need a high-level language to describe builds as much as we need a high-level language to describe configuration. make is really only a dependency tree management system, which is nice but is rather too low level to be of a lot of help. A good build system should understand the sorts of things that libtool understands (not to mention understanding subdirectories so that you don't have to use recursion, understanding how to install files, and so forth). Whether, once you have a high-level configuration system and a high-level build system it makes sense to combine the two is something I'm not sure about. Both projects seem more easily approached in isolation, though. > 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? I really don't like the idea of any non-trivial code being quoted at all. I suppose that if people really want to do that, they can, but for the dozen or so non-trivial probe programs in INN's configure.in, I'd much rather maintain them as separate files, like all the other C code in INN, and not worry about quoting at all. I found Dan Bernstein's method of doing probes for his packages rather elegant in its simplicity; he just builds them like any other program, writes them so that they generate header files, includes those header files where appropriate, and lets make handle all the dependencies. I don't think that scales very well in a few different ways, but something closer to that than what we have now would be better, I think. Autoconf is generally moving in the right direction, and having the same sort of high-level constructs that Autoconf has is the right approach, I think. The things that bother me about Autoconf are the ongoing fights against M4 quoting, the difficulty of writing a brand new test (requiring dropping back to C and shell with a mess of nasty quoting and a ton of restrictive shell coding requirements), and an implementation language that I think is probably discouraging people from contributing more. Something written in a more reasonable programming language would probably help with that; Python is likely the right choice at present, I think, if for no other reason than while Perl is fast to write code in, writing maintainable Perl code requires a lot of discipline. The other thing that I really do think should happen is that the configuration system needs to be well-integrated with a library of portability routines, and with better documentation of exactly what the tests are intended to do. There are some tests in Autoconf (AC_FUNC_GETLOADAVG is one of favorite examples) where the test is essentially worthless to someone who isn't either using a specific replacement routine or knows quite a lot about how to reimplement that function. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
