On Tue, Aug 13, 2002 at 11:35:58PM -0500, Peter Samuelson wrote:
> The big loser here is ARM - it no longer suppresses the sound card
> question for the appropriate boards. But it's just one question, so I
> didn't sweat it too much.
I'd be tempted to drop that set of tests, and just rely on the
On Wed, Aug 14, 2002 at 04:01:18PM +1000, Greg Banks wrote:
> > CONFIG_SERIAL and CONFIG_PCMCIA didn't generate any noise, though.
>
> warning:drivers/parport/Config.in:14:forward declared symbol "CONFIG_SERIAL"
>compared ambiguously to "n"
> warning:drivers/parport/Config.in:14:forward referenc
On Wednesday 14 August 2002 07:49, Peter Samuelson wrote:
> [Kai Germaschewski]
> > It comes of the cost of testing for the architecture, since
> > e.g. s390 does not want to include most of drivers/*, but that means
> > we'd actually collect this knowledge at a centralized place.
>
> What we need
Hi,
On Tue, 13 Aug 2002, Peter Samuelson wrote:
> Mutating the language, long-term, so that it looks less like sh and
> more like a specialised language, is IMO a worthy goal. And I think
> it can be done. The main thing to deal with is adding an alternative
> syntax for 'if' statements which
[Greg Banks]
> warning:drivers/parport/Config.in:14:forward declared symbol "CONFIG_SERIAL"
>compared ambiguously to "n"
> warning:drivers/parport/Config.in:14:forward reference to "CONFIG_SERIAL"
> warning:drivers/parport/Config.in:15:forward reference to "CONFIG_SERIAL"
>
>
> warning:drivers
On Wed, 14 Aug 2002, Greg Banks wrote:
> @@ -330,6 +329,5 @@
> 1 CONFIG_ZORRO
> -34 forward-dependancy
> +23 forward-dependancy
> 11 CONFIG_ISDN_CAPI
> 11 CONFIG_PROC_FS
> -11 CONFIG_SOUND_ACI_MIXER
> 1 CONFIG_BLK_DEV_SD
Could you check that
On Wed, Aug 14, 2002 at 10:22:55AM +1000, Greg Banks wrote:
> The trouble is actually achieving that in shell-based parsers where
> shell code cannot tell whether $CONFIG_EXPERIMENTAL has been used in
> a condition.
Where comes the requirement that we shall keep the existing shell
based config p
[Sam Ravnborg]
> Where comes the requirement that we shall keep the existing shell
> based config parsers?
I don't make that argument - mconfig is the superior solution by far -
but it is certainly the path of least resistance.
As pertains to CONFIG_EXPERIMENTAL and " (EXPERIMENTAL)", it *is*
drivers/char/Config.in still has a complete copy of agp/Config.in.
It's an exact cut-n-paste - the md5sums even match. (:
--- 2.5.31/drivers/char/Config.in~ 2002-08-08 22:43:28.0 -0500
+++ 2.5.31/drivers/char/Config.in 2002-08-14 17:25:20.0 -0500
@@ -173,21 +173,7 @@
Peter Samuelson wrote:
>
> [Greg Banks]
> > [...CONFIG_SERIAL and CONFIG_PCMCIA warnings...]
> >
> Hmmm, either I missed those in your earlier messages, or you didn't
> post them.
Probably I didn't post them. What I posted was a small subset of the full log.
> > > + dep_tristate ' I2C bit-b
Kai Germaschewski wrote:
>
> Could you check that the appended patch solves the CONFIG_ISDN_CAPI
> problem (and doesn't introduce new ones)?
> [...]
> --- 1.3/drivers/isdn/i4l/Config.in Sun Apr 21 23:07:44 2002
> +++ edited/drivers/isdn/i4l/Config.in Wed Aug 14 10:47:42 2002
> @@ -24,22 +2
[I wrote]
> Mutating the language, long-term, so that it looks less like sh and
> more like a specialised language, is IMO a worthy goal. And I think
> it can be done. The main thing to deal with is adding an
> alternative syntax for 'if' statements which doesn't look like
> test(1). More abou
Roman Zippel wrote:
>
> Hi,
>
> On Tue, 13 Aug 2002, Peter Samuelson wrote:
>
> > Mutating the language, long-term, so that it looks less like sh [...]
>
> That doesn't solve any of the more fundamental problems.
Correct, it doesn't.
> 1) We still have 3 config parsers, which produce slightl
[Greg Banks]
> > > > + dep_tristate ' I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C
> > >
> > > Are you sure want this one there?
> >
> > I didn't like it either, but it's needed in a couple odd places. What
> > would you suggest - moving the whole i2c menu up?
>
> Not all the
Peter Samuelson wrote:
>
> [Greg Banks]
> > > > +2 CONFIG_KMOD
> > > > +2 CONFIG_MODULES
> > > > +2 CONFIG_MODVERSIONS
> > > > 2 CONFIG_RTC
> > >
> > > What does that mean? All I did there was to combine two toplevel
> > > menus into one. Did this do somethi
On Thu, 15 Aug 2002 11:52:48 +1000, Greg Banks <[EMAIL PROTECTED]>
wrote:
>Roman Zippel wrote:
>>
>> Hi,
>>
>> On Tue, 13 Aug 2002, Peter Samuelson wrote:
>>
>> > Mutating the language, long-term, so that it looks less like sh [...]
>>
>> That doesn't solve any of the more fundamental problem
Peter Samuelson wrote:
>
> I've come up with syntax I think I'm happy with. It supports most of
> the current [ ] based if statement semantics, can be implemented in
> shell, and (most importantly for me) drops those $ signs. This lays
> the groundwork for stuff like better error checking and a
Greg Banks wrote:
>>[*] "almost enough" because I haven't implemented an 'else'
>>directive. It would be trivial, but I'm not sure what to call it.
>>'else' itself is a shell primitive, so the shell-based parsers
>>(Configure, Menuconfig) wouldn't like it.
>>
>>
>
>You will nee
18 matches
Mail list logo
