On Thu, 25 May 2000, John Cavan wrote:
> "Eric S. Raymond" wrote:
> >
> > James Sutherland <jas88@cam.ac.uk>:
> > > > Even if this weren't true, we'd be trading dependencies and not adding
> > > > one. The Perl stuff in the scripts directory will go away shortly
> > > > (that is, assuming that Linus approves the CML1->CML2 change). This
> > > > would be a net gain in kernel autonomy, as Perl *can't* be compiled away.
> > >
> > > perlcc?
> >
> > Is, I'm told, a kluge much like the freeze tool. You can compile away
> > control structure but you end up carrying around most of Perl as
> > runtime support.
>
> It statically links in libperl.a and behaves similar to writing a C
> program that desires to use Perl's features. The down side is that if
> you rely on Perl modules, you need to include them with the binary as
> they are not compiled in. And why would you want to compile it away
> anyways? I can't even think of a Linux distribution that doesn't include
> it, and many require it.
>
> But I have to ask, what's wrong with Perl for this? It's a well known,
> fast, and flexible tool that allows rapid development and change. Seems
> quite appropriate for this sort of effort.
I agree that Perl is fine. However, someone was suggesting getting rid of
the Perl scripts, apparently on the basis that Python can be "compiled"
with freeze; I pointed out that Perl can do the same.
Basically, I don't think trying to support compiling the kernel on a PC XT
using only MASM is a good idea - if you want to develop software, you need
some software tools.
James.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:15 EST