Re: Background to the argument about CML2 design philosophy

Arjan van de Ven
2001-05-20T21:00:23Z

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