All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pete Zaitcev <zaitcev@redhat.com>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: linux-kernel@vger.kernel.org, zaitcev@redhat.com
Subject: Re: Perl in the toolchain
Date: Fri, 31 Jan 2003 20:06:33 -0500	[thread overview]
Message-ID: <200302010106.h1116XP08674@devserv.devel.redhat.com> (raw)
In-Reply-To: <mailman.1044055681.1939.linux-kernel2news@redhat.com>

> 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.

Sure, but I want to self-host, too. I can cross-compile kernels,
but cross-compiling modutils is an insane pain, for example,
so to this day I never ever used Rusty's new shiny module loader,
and thus I never got around to fix dots in export symbols.

For the record, the userland which I posess does have a somewhat
working Perl RPM, which originates from Red Hat 5.2, I believe.
So, I cannot invoke "missing perl" argument in good conscience.
However, I shudder to think what happens if I need to rebuild it
for some reason.

> 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.

I hear you. Actually, your argument comes in force only after a
non-trivial amount of mungling, but to slay your argument
I need to see your klibc stuff first.

> Adding some final thoughts, perl is already used in nooks and crannies 
> in the build system.  Instead of being motivated to stomp those out, 
> please [respectfully!] consider that the Perl scripts might be there 
> because an evaluation of the best tool for the job took place. 
> script_asm.pl in drivers/scsi is a favorite example here.

There's also a subject of a skillset. I know nil about Perl.
(ok, I hacked sirc long ago. I don't think it counts.)
This means I cannot debug and fix your text mungling.
Perl not only has a reputation for being perfect for text
mungling, but also a reputation for being unreadable by anyone
but the author (due to the fact that the same thing can be
expressed in a half a dozen different ways - so says Larry Wall
himself in my Perl book (ok, he actually makes strict subsets
of knowledge, which helps very little in my example ("Programming
Perl", p33 - What You Don't Know...))).

-- Pete

  parent reply	other threads:[~2003-02-01  0:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-31 18:39 Perl in the toolchain Pete Zaitcev
2003-01-31 19:41 ` Kai Germaschewski
2003-01-31 19:48   ` Jeff Garzik
2003-01-31 19:55     ` Mr. James W. Laferriere
2003-01-31 20:41     ` Sam Ravnborg
2003-01-31 22:50       ` Ben Greear
2003-01-31 21:38     ` J.A. Magallon
2003-01-31 22:22       ` Sam Ravnborg
2003-01-31 23:23         ` Jeff Garzik
2003-02-01  0:29           ` H. Peter Anvin
2003-02-01 12:12           ` Sam Ravnborg
2003-01-31 23:40         ` J.A. Magallon
     [not found]         ` <mailman.1044055681.1939.linux-kernel2news@redhat.com>
2003-02-01  1:06           ` Pete Zaitcev [this message]
2003-02-01  6:02             ` Ryan Anderson
2003-01-31 22:51       ` Roman Zippel
2003-01-31 23:27       ` Jeff Garzik
2003-01-31 23:40         ` J.A. Magallon
2003-01-31 23:40           ` Jeff Garzik
2003-02-01  0:01           ` Roman Zippel
2003-02-01  0:05             ` J.A. Magallon
  -- strict thread matches above, loose matches on Subject: below --
2003-01-31 20:13 Ed Vance
2003-02-01  3:28 ` Scott Robert Ladd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200302010106.h1116XP08674@devserv.devel.redhat.com \
    --to=zaitcev@redhat.com \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.