[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0706230855180.26568@fbirervta.pbzchgretzou.qr>
Date: Sat, 23 Jun 2007 08:57:48 +0200 (CEST)
From: Jan Engelhardt <jengelh@...putergmbh.de>
To: Roman Zippel <zippel@...ux-m68k.org>
cc: Satyam Sharma <satyam.sharma@...il.com>,
Trent Piepho <xyzzy@...akeasy.org>,
Mauro Carvalho Chehab <mchehab@...radead.org>,
toralf.foerster@....de, Oliver Neukum <oneukum@...e.de>,
LKML <linux-kernel@...r.kernel.org>,
Luca Risolia <luca.risolia@...dio.unibo.it>
Subject: Re: Kconfig troubles when using menuconfig - Was: [patch]Re:
[linux-usb-devel] linux-2.6.22-rc5-gf1518a0 build #300 failed in zc0301_core.c
On Jun 23 2007 02:26, Roman Zippel wrote:
>On Sat, 23 Jun 2007, Satyam Sharma wrote:
>
>> But why? Let it do just one thing, and do it well. Is their
>> any requirement anywhere that requires us to give a dual
>> meaning to these menuconfig objects -- i.e. to also control
>> the inclusion / exclusion of code from the kernel as well as
>> also for the presentation + user interface purpose that it
>> currently serves?
>
>This getting ridiculous. :-(
>You're the one who is attaching a new meaning to it.
>Any config symbol has multiple meanings depending on the context, the menu
>property only changes _one_ of them, you want to drastically redefine it
>and that's not going to happen.
Would it make sense to define a new entity called "configmenu" (or something
else) that is equivalent to menuconfig with the following changes?
* it creates a CM_ variable instead of a CONFIG_ one
* the CM_ symbols are not available to Makefiles or C files
(so in fact, just to menuconfig and that they are listed in .config)
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists