lkml.org 
[lkml]   [2001]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Background to the argument about CML2 design philosophy
On Sun, May 20, 2001 at 04:47:00PM -0400, Eric S. Raymond wrote:
> In order to prevent that happening, I would like to have some recognized
> criterion for configuration cases that are so perverse that it is a
> net loss to accept the additional complexity of handling them within the
> configurator.

"It doesn't compile/link" would be a good one. "It requires subsystem FOO to
operate" is another (think about IDE DMA drivers and the IDE subsystem, or
NIC drivers vs CONFIG_NET)

> A lot of people (including, apparently, you) are saying there are no such
> cases. I wonder if you'll change your minds when you have to handle the
> overhead yourselves?

Somehow the current overhead isn't that high. You might argue that the
current Config.in is broken given my definition. That is fixable with a day
of work; I've been doing so on a regular basis with the tooling I wrote for
automatic testing of this.

Maybe it would be possible to separate "hard" dependencies like the current
system has with the "soft" ones one needs for entry-level configtools. Or
maybe it needs 2 files for that.. CML1 style (style, maybe not syntax) ones
and the newstyle info.


I liked the suggestion where the "automatic" derivations got turned into
manual ones for expert mode...

I haven't tried CML2 yet (I've yet to find a suitable .deb of Python2 for my
Debian Potato playbox) so I don't know if that is actually possible, or that
it requires some redesign.

Greetings,
Arjan van de Ven


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.238 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site