On Wednesday 16 December 2009 20:43:01 H. Peter Anvin wrote: > On 12/16/2009 05:39 PM, Roland Dreier wrote: > > Is there any reason not to apply the patch below, to allow more awk > > implementations to be used? After all, it's not like we're going to put > > non-ASCII characters into the map file... > > I guess the question is if it will break under any other circumstances, > but I guess we can find those when we get to them. > > There was a long discussion about the use of awk on IRC today. > Apparently mawk, in particular, is actively broken, because the > maintainer believe that POSIX is crap. There are quite a few issues > with it, according to reports. if the kernel specifies posix, and that implementation doesn't do posix, then that implementation doesn't build the kernel. Blacklisting known broken implementations makes a certain amount of sense. > We need a sane scripting language available to the kernel build, and > given all the problems we have had with different versions or even just > sometimes different builds of sh, awk, and even bc -- plus the fact that > those utilities just don't necessarily do what we want makes it very > frustrating. 1) Posix exists for a reason. 2) Busybox implements what the kernel has needed to build. (I test this every release, and I fix it where necessary.) > Personally I think a dependency on Perl is better than the > mess we're in; I understand other people disagree. Vehemently. > What is definitely > not acceptable, however, is the status quo. The situation is, quite > frankly, ridiculous enough that perhaps the right thing to do is to > write a small scripting engine and bundle it with the kernel. Something > that does what we need it to do, but is only one implementation and > something we can extend at will if need be. *shrug* That's one way to avoid environmental dependencies. > -hpa Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
