Hi,
On Mon, 12 Aug 2002, Peter Samuelson wrote:
> tristate DRV
> dep_mbool DRV_OLD DRV
>
> dep_mbool COMMON_OPT DRV
> dep_mbool OLD_OPT1 DRV_OLD
> dep_mbool OLD_OPT2 DRV_OLD
> dep_mbool NEW_OPT1 DRV !DRV_OLD
> dep_mbool NEW_OPT2 DRV !DRV_OLD
This way you can't compile old and new driver as modu
Hi,
On Tue, 13 Aug 2002, Greg Banks wrote:
> > This doesn't has be
> > very painful, I have a tool that can convert most of the current config
> > into whatever you want.
>
> The problem is deciding what the original rules were supposed to mean, and
> then reproducing that behaviour exactly in t
Roman Zippel wrote:
>
> On Tue, 13 Aug 2002, Greg Banks wrote:
>
> > The problem is deciding what the original rules were supposed to mean, and
> > then reproducing that behaviour exactly in the new language. The alternative
> > is fixing the problems as we convert, but then we end up with CML2
Peter Samuelson wrote:
>
> [...] what would be
> *really* nice would be a way to determine that a particular "forward
> declared symbol" is actually a "never-in-this-arch declared symbol".
Ok, here it is.
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with f
On Tue, Aug 13, 2002 at 01:23:19PM +1000, Greg Banks wrote:
>
> 977missing-experimental-tag
> 113spurious-experimental-tag
> 145variant-experimental-tag
> 30 inconsistent-experimental-tag
> 13 missing-obsolete-tag
> 41 spurious-obsolete-tag
> 25 variant-obsolete-tag
Ho
[Greg Banks]
> Ok, here it is.
Thanks again. It will take some time to double-check what I termed
the "false positives", but now you've reduced the "interesting cases"
down to 30 symbols.
(BTW, the format is great - I can use 'M-x compile' and 'M-x
next-error' and Emacs pulls up files and li
[Sam Ravnborg]
> How about extending the language (side effect) to automagically
> append (EXPERIMENTAL) or (OBSOLETE) to the menu line, if dependent
> on those special tags?
I've thought about that too. Menuconfig already has magic code to
append ' (NEW)' if it hasn't seen a symbol before.
Yo
On Tue, 13 Aug 2002, Peter Samuelson wrote:
> CONFIG_PROC_FS is needed by ISDN hysdn. That's actually in my opinion
> more of a "general kernel facility" than a filesystem. Eh?
Well, the use in hysdn can (and should) die, possibly by adding an
#ifndef CONFIG_PROC_FS
#error This driver won't wo
[Kai Germaschewski]
> Well, it'd be nice to first "fix" the dep_* statements so that they
> don't break when that change is done (i.e. in this case, moving
> IDESCSI behind CONFIG_SCSI.
Yes. That's my current plan.
> Basically, extend the "source" command to do a grep CONFIG_* in the
> file to
On Tue, 13 Aug 2002, Greg Banks wrote:
> Kai Germaschewski wrote:
> >
> > But so the change would be a good thing, right? It would make the behavior
> > consistent between all configuration tools,
>
> Sorry, I don't understand what you're getting at. Currently the behaviour is
> consistent bet
Sam Ravnborg wrote:
>
> On Tue, Aug 13, 2002 at 01:23:19PM +1000, Greg Banks wrote:
> >
> > 977missing-experimental-tag
> > 113spurious-experimental-tag
> > 145variant-experimental-tag
> > 30 inconsistent-experimental-tag
> > 13 missing-obsolete-tag
> > 41 spurious-obsolet
Peter Samuelson wrote:
>
> (BTW, the format is great - I can use 'M-x compile' and 'M-x
> next-error' and Emacs pulls up files and lines for me.)
This is not a coincidence.
> CONFIG_SCSI should be defined earlier, like in the "Block Devices"
> menu. Then again, 'sg' is not a block device so th
Kai Germaschewski wrote:
>
> > > So you agree a bit of spring cleaning wouldn't hurt, right? ;)
> >
> > Absolutely, and I have a catalogue of dust puppies to help that process ;-)
>
> Okay. Let me first state that I do not really have the time to get
> involved currently. ISDN4Linux and other pe
Peter Samuelson wrote:
>
> [Kai Germaschewski]
>
> sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any case
> it is not hard to support both syntaxes - once the transition is
> complete,
Does "complete" mean all the ports have also made the change and been merged back?
or reasonabl
[I wrote]
> > sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any
> > case it is not hard to support both syntaxes - once the transition
> > is complete,
[Greg Banks]
> Does "complete" mean all the ports have also made the change and
> been merged back?
Either that, or, Linus gets
Peter Samuelson wrote:
>
> [Greg Banks]
> > Does "complete" mean all the ports have also made the change and
> > been merged back?
> [...]
> Actually I suspect it would be more like the C99 thing: after the new
> syntax is added, we start doing [TRIVIAL] patches to clean out the
> old, and eventu
[Greg Banks]
> define_bool CONFIG_QUUX y
>
> bool 'Set this symbol to ON' CONFIG_FOO
>
> if [ "$CONFIG_FOO" = "y" ]; then
> bool 'Here QUUX is a query symbol' CONFIG_QUUX
> fi
It's (somewhat) well-known that things tend to fly apart when you try
to redefine a symbol. I d
[Greg Banks]
[I wrote]
> > (BTW, the format is great - I can use 'M-x compile' and 'M-x
> > next-error' and Emacs pulls up files and lines for me.)
>
> This is not a coincidence.
Indeed not - if you hadn't already used that format I would have
munged it. Grew up on gcc, so this is my favorit
Here's another one - this should fix the forward dependency between
CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config
into the "Multimedia" menu - where I think it belongs anyway.
The big loser here is ARM - it no longer suppresses the sound card
question for the appropriate bo
On Tue, 13 Aug 2002, Peter Samuelson wrote:
> Here's another one - this should fix the forward dependency between
> CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config
> into the "Multimedia" menu - where I think it belongs anyway.
Hmmh, makes sense to me, but there will probably
Kai Germaschewski wrote:
>
> On Wed, 14 Aug 2002, Greg Banks wrote:
>
> > Peter Samuelson wrote:
> > >
> > > [Greg Banks]
> > > > Does "complete" mean all the ports have also made the change and
> > > > been merged back?
> > > [...]
> > > Actually I suspect it would be more like the C99 thing: a
[I wrote]
> > Here's another one - this should fix the forward dependency
> > between CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the
> > sound config into the "Multimedia" menu - where I think it belongs
> > anyway.
[Kai Germaschewski]
> Hmmh, makes sense to me, but there will probably
On Wed, 14 Aug 2002, Greg Banks wrote:
> Peter Samuelson wrote:
> >
> > [Greg Banks]
> > > Does "complete" mean all the ports have also made the change and
> > > been merged back?
> > [...]
> > Actually I suspect it would be more like the C99 thing: after the new
> > syntax is added, we start do
Peter Samuelson wrote:
>
> > > [...] Perhaps a "kernel subsystems" submenu under "general setup",
> > > or even as a toplevel menu.
> >
> > Sounds like a good idea. You could put CONFIG_SERIAL and CONFIG_PCMCIA
> > in there too.
>
> CONFIG_SERIAL and CONFIG_PCMCIA didn't generate any noise, th
Kai Germaschewski wrote:
>
> On Tue, 13 Aug 2002, Peter Samuelson wrote:
>
> I think that's exactly where this effort should start. For example, the
> SCSI patch didn't do this, though AFAICS it would be nicely possible to
> unconditionally source drivers/scsi/Config.in and then have the if in
>
Peter Samuelson wrote:
>
> Here's another one - this should fix the forward dependency between
> CONFIG_SOUND and CONFIG_SOUND_ACI_MIXER, by moving the sound config
> into the "Multimedia" menu - where I think it belongs anyway.
>
> [...]
> -if [ "$CONFIG_ARCH_ACORN" = "y" -o \
> - "$CONFIG
26 matches
Mail list logo
