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 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 is an
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
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 the
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
[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-banging
[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 about
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 slightly
[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 way up to the new
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 something bad?
Apparently.
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 problems.
Correct, it
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 auto
14 matches
Mail list logo
