Re: Perl in the toolchain

["H. Peter Anvin" <hpa@zytor.com>]

Followup to:  <3E3B0557.3070400@pobox.com>
By author:    Jeff Garzik <jgarzik@pobox.com>
In newsgroup: linux.dev.kernel
> 
> This is a logically correct argument, but also one that ignores basic 
> numbers.
> 
> The fact of the matter is, the area of build tools matters most to 
> people who cross-compile their kernels, because every tool is generally 
> hand-built rather than automatically installed on their Linux system. 
> For this audience, as well as the typical non-cross-compiling kernel 
> developer, Perl is on their system.
> 
> However, that fact is less significant than the more basic and core 
> argument:
> 
> klibc uses perl for text munging.  i.e. one of Perl's acknowledged 
> strengths.  This is not a case of choosing a favorite script language, 
> but instead a case of choosing "the right tool for the job."  Regardless 
> of whether you think Perl is line noise :) or not, from a technical 
> basis Perl is clearly superior to sed+awk in this case.
> 

Thanks Jeff :)

To emphasize things a bit further, Perl is:

a) good at munging text;
b) available on basically all development systems;
c) not host- or target-specific.

Thus, I cannot see it as being an issue, and I challenge anyone to
find a machine on which they regularly build kernels which doesn't
have Perl.  Like it or not, today it's as much a part of a
general-purpose Unix platform as sed or awk.

Yes, you can write complete shit code in Perl.  You can write shit
code in any language (Perl does, however, make it easier, so if you're
programming in Perl you need to watch out for this.)  Yes, you can
require 47 different obscure interdependent modules which were just
released last week on CPAN, but you can require an equivalent number
of obscure libraries in C.  Doing that, or require features only
available in very recent versions of Perl, would be wholly
inappropriate for the kernel build.  My personal rule of thumb is that
it should work at least as far back as Perl 5.004.

There is one klibc script which possibly ought to be rewritten, and
that is the one that uses Digest::MD5 which may not be available on
some very old platforms.  If so, I'd probably just include the MD5
digest code in the script itself, rather than having to deal with C
code that is compiled for the host in the klibc tree.

	-hpa

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: cris ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64