Hello, Tom! > The maintainers have to struggle to write portable shell code; they have > to constantly avoid the temptation to introduce new tool dependencies in > the wrong place; they can't even rely on GNU Make.
Maybe I'm missing something, but portable code is easier to maintain. It's a simpler programming language. If somebody heavily uses GNU Make features, I would have to learn them to fix the makefile. Workarounds for bugs is a separate issue. The shell code written in configure.in is directly exposed to every buggy shell out there. Not every programmer is supposed to know all bugs in all subshells, and this should not disqualify him or her from contributing fixes to the configuration tools of a particular project (I mean little niche programs, like gtkyahoo, not Autoconf itself). This problem is not so acute in Automake - it writes the rules for you, and in most cases you don't need your own rules. With Autoconf, you often need to implement processing of user options. For example, there are two libraries, A and B, and only one can be used. There are at least (not counting --with-A=/path/to/A) 2 possibilities for each library (present and absent) and 3 possibilities for each option, (--with-A, -without-A, no option), which makes 36 combinations. There are no ready macros to implement user-friendly logic, i.e. printing something like "you don't want to use A, but I cannot find B". If you are going to make a fork, add a well-behaving shell to the requirements and leave out everything else. I know a project with configure script longer than 500k. Uncompressed sources of ash with function support are smaller than that. -- Regards, Pavel Roskin