[cc: trimmed]
On Thu, Oct 10, 2002 at 10:18:06AM -0400, Jeff Garzik wrote:
> Personally I don't care about Config dependency checking... they are
> not modified often enough to affect me, and even if they did, dependency
> checking based on changes to Config files can get ugly, AFAICS. I just
On Thu, Oct 10, 2002 at 01:32:11PM -0400, Jeff Garzik wrote:
> The kernel is written for people with a clue. For people without a
> clue, they should use a vendor kernel or ESR's Aunt-Tillie-friendly system.
>
> Dumbing-down the kernel is never the right answer.
Well I'm not talking about dumb
Roman Zippel wrote:
> On Tue, 8 Oct 2002, Linus Torvalds wrote:
>>Some things made me go eww (but on the whole details):
>>
>> - I'd prefer the Config.in name, since this has nothing to do with
>> building, and everything to do with configuration.
>
>
> Fine with me.
> (jgarzik, I think you're
Roman Zippel wrote:
> Hi,
>
> On Wed, 9 Oct 2002, Jeff Garzik wrote:
>
>
>>Well, my basic preference is
>>
>>* something other than Config.new (the original name in your config system)
>>* something other than Config.in
>>
>>I think it is a mistake to name a totally different format the same na
On 2002.10.09 Randy.Dunlap wrote:
>On Thu, 10 Oct 2002, Brendan J Simon wrote:
>
>| Roman Zippel wrote:
>|
>| >>But the fact that xconfig depends on QT is going to make some people hate
>| >>it.
>| >>
...
>| This is a difficult one. GUI's toolkits are a bit of religion
>| (fundamentalist types t
On Thu, 10 Oct 2002, Brendan J Simon wrote:
| Roman Zippel wrote:
|
| >>But the fact that xconfig depends on QT is going to make some people hate
| >>it.
| >>
| >>
| >This should be rather easily fixable, but it has to be done by someone who
| >is more familiar with whatever prefered toolkit. I'm
On Wed, 9 Oct 2002, Peter Samuelson wrote:
| [Roman Zippel]
| > The problem is that the config syntax will continue to evolve and
| > currently I prefer to keep the library close to the matching config
| > files.
| > I think I can keep the basic structure constant, but new options will be
| > add
Brendan J Simon wrote:
> Simple and boring but how about "Config2.in" or "Config-2.in" ???
no offense intended, but:
ug...
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
__
On Wed, 9 Oct 2002, Sam Ravnborg wrote:
| On Wed, Oct 09, 2002 at 12:28:44PM -0700, Randy.Dunlap wrote:
| >
| > The kernel would still have the text-mode configurator.
| The way I read the original post by Christoph Hellwig - nope.
| If the kernel config library is outside the kernel then the
| t
Linus Torvalds wrote:
> So instead: how about just "Config" for the main per-directory
> configuration file, with sub-config's being "Config.3c5xx" and
> "Config.rrunner".
I like it. I'm glad Sam mentioned sub-configs such as Config.3c5xx,
that's something that was discussed a while ago [and a
Roman Zippel wrote:
> Hi,
>
> On Wed, 9 Oct 2002, Jeff Garzik wrote:
>
>
>>Which implies that the equivalent of "source drivers/net/Config*"
>>(wildcarding) in Roman's system would be useful. Or maybe "source
>>drivers/net" and it knows that when given a directory it should scan for
>>all Conf
On Wed, 9 Oct 2002, Linus Torvalds wrote:
| On Wed, 9 Oct 2002, Randy.Dunlap wrote:
| >
| > stick with TCL/TK, like xconfig currently uses ?
|
| Too ugly. I actually think QT is a fine choice, I just suspect that it's
| going to cause political issues.
|
| My favourite approach by far is to actua
Sam Ravnborg wrote:
> [cc: trimmed]
>
> On Thu, Oct 10, 2002 at 10:18:06AM -0400, Jeff Garzik wrote:
>
>>Personally I don't care about Config dependency checking... they are
>>not modified often enough to affect me, and even if they did, dependency
>>checking based on changes to Config files
Sam Ravnborg wrote:
> But there is a good reason why they do it.
> Take a look at dirvers/video/Config.in for example.
> See the size of the big if's. They span several pages if not the whole file.
> Why they do this is simple. Only check for PCI once, and group all
> PCI stuff there.
> With the s
14 matches
Mail list logo
