Messages in this thread |  | | Date | Sun, 20 May 2001 16:59:52 -0400 | From | Arjan van de Ven <> | Subject | Re: 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/
|  |