> There are some things worth worrying about, but I don't think this is
> one of them. The kernel can be cross-compiled, so its build
> requirements are really not that important. Nobody sane ever compiles
> Linux on an embedded system (by definition if it's embedded it's too
> small to do that sort of thing), and 99.999% of non-embedded Linux
> systems have Perl on them.
Apparently, I'm not sane then.
I cross compile just enough of a native environment to be able to
recompile itself, and then I boot it under qemu (where I have unlimited
memory, hard drive, and can leverage cheap x86 CPU power) and native
compile under an emulator. Native compiling is MUCH easier than cross
compiling, in general.
I accelerate this by using distcc to call out to the cross compiler
(through the virtual network). That's optional, but provides a nice
speed boost without taking away from the fact that header #including and
library linking and ./configure and all the _hard_ bits are run natively
inside the emulator, where they "just work" without having to do the
intricate and extensive "explaining things to the build, with a brick"
that cross compiling requires.
> A Perl installation requires about 30Mb. There's no way you could
> sensibly compile a modern Linux kernel on a system with that little
> RAM, so what you're saying is we should optimize the kernel build
> process for systems that have less disk space than we need memory to
> complete the compilation?
No, I'm saying that gratuitous environmental dependencies more or less
killed the gnucash project, and Linux has until now gone out of its way
to avoid them. There's _shipped logic to avoid the need for lex and yacc
in kconfig, and you can run "oldconfig" without curses. This perl
dependency did not previously exist, and was introduced for very little
reason. Now there's talk of adding perl to kbuild. So understanding the
build process would now involve knowing three languages (Because nothing
says "maintainability" like perl. Or for that matter, having to know
four different programming languages (C, BASH, gnu make, perl) to follow
Of course Python is just as widely deployed, so let's add that too. (I
love Python. It doesn't belong in the kernel build unless perhaps you
use it to REMOVE the dependencies on make and bash.) And java's GPLv2
now, why not throw that in as well? Did you know PHP can be used
standalone outside of web browsers? And there are tons of fans of emacs
Where does it end?
> (And no, I don't much like Perl: I much prefer Python and C. But still,
> this is a waste of human effort.)
Perl is not a language. Perl is a program. There are dozens of C
python interpreter implemented in java. But there is only a single
implementation of perl, and attempts by the original development team to
reimplement perl (in parrot) failed. There is no standard, just a
codebase that may or may not run your program.
The open source world was upset about Word files being considered a
standard, and uncomfortable back when "it works on Netscape" was the sole
definition of HTML, but Perl gets a pass on this. I still don't
understand why. The IETF always insisted on two independent
implementations before calling anything a standard. To this day, Perl
wouldn't pass muster there.
But that's a side issue. So is perl's status as a write-only language.
My objection is over adding complexity to the build process (in the form
of environmental dependencies) without a compelling reason that outweighs
the added complexity.