Bruce Korb <[EMAIL PROTECTED]> writes: > Autoconf is about two different purposes. First, the developer needs to > know what features are present or lacking on a target system; then the > ultimate builder uses its facilities to tell it what to enable or not > and where to put the results. That's two interfaces for one product.
Or, to put that another way, Autoconf both probes system capabilities automatically and supports manual configure-time options. For the former, you need some way of overriding when Autoconf guesses wrong. For the latter, you don't want Autoconf guessing at all (but you do need some way of telling it what to do from the command line, since those of us with automated build systems find this *much* easier to deal with than maintaining patches to configuration files the user is supposed to "edit"). These should probably be split into two separate tools, frankly. > Why am I having this sense of deja vu? > http://sc-archive.codesourcery.com/sc_config These results were very depressing. None of them tackled what I consider to be the major problem, namely a coherent and simple way to write probes. BuildConf is basically Autoconf plus Automake, which is useful but not what I want and which isn't going to be any easier to write probes in than Autoconf is now. It also brings in the whole build system problem, which is a different issue entirely. The build system problem needs solving in a more comprehensive way by again providing a higher-level interface where operations like "build a shared library" are expressable notions in the language that the programmer is using. Again, Automake attempts to get there, but its reliance on portable make as the foundation results in serious limitations. ConfBase and Tan appear to be all about organizing the presentation of the probes rather than writing the probes itself. Not interesting to me. SapCat is the only one of the group that really seemed to be heading the direction I'm interested in seeing things go, but it again is also trying to solve the build problem, plus when you get down to the bit about how to write tests, it again looks basically like Autoconf. I don't think there's any way to get around the fact that in order to have a really easy configuration probe language, you need an underlying tool with intimate knowledge of the programming languages and environments being probed. You can't expect the user to tell the tool how to check if a function exists; the probe language has to already know how. The most that's really acceptable is to ask the programmer to provide a test case that fails, and the interface for doing that has to be as clean as possible and involve as little distortion of the original test code as possible. Maybe the problem as I'm thinking of it is just too hard to really fully solve. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
