Russ Allbery wrote: > In my opinion, the right direction to move for something like Autoconf is > *away* from text processing and towards what Autoconf really is, namely a > programming language for writing testing scripts.
Starting with the interface is essentially always the way to start. Once you have a clear definition of how users communicate their needs, then you can work on how to go about it. 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. Since the installer interface doesn't raise immense criticism, take that one as a given. So, design the other one and then figure out how best to implement it. Why am I having this sense of deja vu? http://sc-archive.codesourcery.com/sc_config > The little bit that I played with AutoGen, I found it to be even more > unreadable than Autoconf and a step in the wrong direction. The template > model moves things even further towards a macro-based text expansion > utility, which is exactly the problem with m4. Different tools for different problems. Using AutoGen would assumes that the "expressing your needs" --> "portable shell script" transform was going to persist. It is extremely adept at that. If you have something else in mind, it may not be the right tool. If you have useful criticisms of AutoGen, I'm also interested in hearing them. :-)
