All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J.A. Magallon" <jamagallon@able.es>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: "J.A. Magallon" <jamagallon@able.es>, linux-kernel@vger.kernel.org
Subject: Re: Perl in the toolchain
Date: Sat, 1 Feb 2003 00:40:21 +0100	[thread overview]
Message-ID: <20030131234021.GE1541@werewolf.able.es> (raw)
In-Reply-To: <3E3B066B.8010905@pobox.com>; from jgarzik@pobox.com on Sat, Feb 01, 2003 at 00:27:39 +0100


On 2003.02.01 Jeff Garzik wrote:
> J.A. Magallon wrote:
> > On 2003.01.31 Jeff Garzik wrote:
> > 
> >>On Fri, Jan 31, 2003 at 01:41:26PM -0600, Kai Germaschewski wrote:
> >>
> >>>Generally, we've been trying to not make perl a prequisite for the kernel 
> >>>build, and I'd like to keep it that way. Except for some arch specific 
> >>
> >>That's pretty much out the window when klibc gets merged, so perl will
> >>indeed be a build requirement for all platforms...
> >>
> > 
> > 
> > So in short, kernel people:
> > - do not want perl in the kernel build
> > - allow qt to pollute the kernel to have a decent gui config tool
> > - have to rewrite half perl features in C
> > - but perl will be needed anyways
> > 
> > instead of
> > - do all parsing in perl, that is what perl is for and what is mainly done
> >   in kconfig scripts
> > - do the config backend in perl, and...
> > - do the gui in perl-XXX, so you can have perl-GTK, perl-GTK2, perl-QT or 
> >   perl-Tk, even perl-Xaw (so you get rid of tcl/tk)
> > 
> > I really do not understand...
> 
> 
> Well, you appear to be taking the superset of opinions, which is 
> guaranteed to generate a paradox, I should think ;-)
> 
> Specifically regarding kconf, it does not require Qt; Qt is merely an 
> optional piece.
> 
> For Perl, yes I personally think it is needed anyway.  And re-creating 
> Perl's features in C, just to avoid Perl, is not the best technical 
> solution when developers already have Perl installed.
> 

As someone said, parsing and string processing is one of the jobs in kernel
config. Kernel gurus decided to rewrite the thing in C to avoid the lacks
in the current bash-ish kconfig, because writing logic for dependencies,
checks and so on is a pain...so let's rewrite the logic handling, _and_ the
string processing, btw.
The easies way (from my point of view): write Perl::KConfig in C to do the logic
hard work and build the big thing in perl. That will be putting a perl
interface on top of klibc ?

-- 
J.A. Magallon <jamagallon@able.es>      \                 Software is like sex:
werewolf.able.es                         \           It's better when it's free
Mandrake Linux release 9.1 (Cooker) for i586
Linux 2.4.21-pre4-jam1 (gcc 3.2.1 (Mandrake Linux 9.1 3.2.1-5mdk))

  reply	other threads:[~2003-01-31 23:30 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
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 [this message]
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=20030131234021.GE1541@werewolf.able.es \
    --to=jamagallon@able.es \
    --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.