All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Verych <olecom@flower.upol.cz>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Roman Zippel <zippel@linux-m68k.org>,
	"Elyse M. Grasso" <emgrasso@data-raptors.com>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Eric Van Hensbergen <ericvh@gmail.com>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	kbuild-devel@lists.sourceforge.net,
	Andreas Herrmann <aherrman@arcor.de>
Subject: Re: A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL)
Date: Sat, 6 Oct 2007 22:47:21 +0200	[thread overview]
Message-ID: <20071006204721.GF22435@flower.upol.cz> (raw)
In-Reply-To: <20071006185920.GA8005@uranus.ravnborg.org>

On Sat, Oct 06, 2007 at 08:59:20PM +0200, Sam Ravnborg wrote:
> > Maintenance and acceptance of the m4/make/perl/C/ncurses community of my
> > mainly `TERM=linux ; sed && sh' approach is more important for me.
> 
> There is noone having trouble with ncurses dependency today.

Who wants to meet a zombie anyway?

== Message-ID: <20051212004606.31263.37616.stgit@machine.or.cz> ==
From: Petr Baudis
Subject: [PATCH 3/3] [kconfig] Direct use of lxdialog routines by menuconfig
Date: Mon, 12 Dec 2005 01:46:06 +0100

After three years, the zombie walks again!  This patch (against the latest
git tree) cleans up interaction between kconfig's mconf (menuconfig
frontend) and lxdialog. Its commandline interface disappears in this patch,
instead a .so is packed from the lxdialog objects and the relevant
functions are called directly from mconf.

== * ==

> And perl is not yet mandatory for a kernel build expect
> for a few architectures.

Not build per se, but perl mind share of the people. Did they ever
looked into `strace`, when running (kind of) `perl simple-regex`?

Maybe there weren't right people to manage things easily in shell?
Reinventing parser was a major step back, whatever anyone can say.

== (seems like not original ID) 17982.5167906985$1029355529@news.gmane.org ==
From: Sam Ravnborg
Subject: Get rid of shell based Config.in parsers?
Date: Wed, 14 Aug 2002 22:14:00 +0200

[...]

I dislike seeing arguments that this is not easy/possible in shell based
parsers. If the chosen technology does not fit the problem domain
then it's about time to shift technology.

        Sam
== * ==

== Message-ID: <Pine.LNX.4.44.0208151048330.3130-100000@home.transmeta.com> ==
From: Linus Torvalds
Subject: Re: Get rid of shell based Config.in parsers?
Date: Thu, 15 Aug 2002 10:51:03 -0700 (PDT)

On Wed, 14 Aug 2002, Sam Ravnborg wrote:
>
> Where comes the requirement that we shall keep the existing shell
> based config parsers?

I use them exclusively.

It is far and away the most convenient parsing - just to do "make
oldconfig"  (possibly by making changes by hand to the .config file
first).

As far as I'm personally concerned, the shell parsers are the _only_
parser that really matter. So if you want to replace them with something
else, that something else had better be pretty much perfect and not take
all that long to build.

                Linus
== * ==

> m4 is not used by the kernel - to my best knowledge.

That was a rhetoric (i guess) statement. But it *is* used to
configure/build almost all tools, currently directly or indirectly
kbuild/kconfig uses.

`m4 'make "shell"'`

*OR*

`To quote lguest 'To quote David Wheeler:

"Any problem in computer science can be solved with
 another layer of indirection."'`

That's my personal view. And after 5-6 years of the "development", i
can see the "results". Again, will see.
____

  reply	other threads:[~2007-10-06 20:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-18  8:05 [PATCH] 9p: fix compile error if !CONFIG_SYSCTL Andreas Herrmann
2007-09-18 18:53 ` roel
2007-09-18 20:15   ` Andreas Herrmann
2007-09-20  6:31 ` Andrew Morton
2007-09-20  7:23   ` Andreas Herrmann
2007-09-27 21:40   ` Nick Piggin
2007-09-28 14:34     ` Linus Torvalds
2007-09-28  0:05       ` Nick Piggin
2007-09-28 17:11         ` Arjan van de Ven
2007-09-28 17:12         ` Elyse M. Grasso
2007-10-01  7:27           ` A bit of kconfig rewrite (Re: [PATCH] 9p: fix compile error if !CONFIG_SYSCTL) Oleg Verych
2007-10-01  8:05             ` Sam Ravnborg
2007-10-01 12:53             ` Elyse M. Grasso
2007-10-05  2:35             ` [kbuild-devel] " Roman Zippel
2007-10-06 15:26               ` Oleg Verych
2007-10-06 16:03                 ` Linus Torvalds
2007-10-06 17:51                   ` Oleg Verych
2007-10-06 18:59                     ` Sam Ravnborg
2007-10-06 20:47                       ` Oleg Verych [this message]
2007-10-06 21:10                         ` Sam Ravnborg
2007-10-06 22:07                           ` Oleg Verych
2007-10-07  9:49                             ` Geert Uytterhoeven
2007-10-08 20:22                             ` Sam Ravnborg
2007-10-08 21:25                               ` Oleg Verych

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=20071006204721.GF22435@flower.upol.cz \
    --to=olecom@flower.upol.cz \
    --cc=aherrman@arcor.de \
    --cc=akpm@linux-foundation.org \
    --cc=emgrasso@data-raptors.com \
    --cc=ericvh@gmail.com \
    --cc=kbuild-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=sam@ravnborg.org \
    --cc=torvalds@linux-foundation.org \
    --cc=zippel@linux-m68k.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.