Re: proposal to fork the build-tools projects

[Pavel Roskin]

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