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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
