>[ Btw, Jeff, any reason why you changed your name to "Legacy Fishtank"? It
> took a few mails before I noticed that it also said "garzik" in the
> fine print;]
>
>One thing that this big flame-war has brought up is that different people
>like different things. There may be a simpler solution to this: have the
>core dependency files generated from some other file format.
>
>My pet peeve is "centralized knowledge". I absolutely detested the first
>versions of cml2 for having a single config file, and quite frankly I
>don't think Eric has even _yet_ separated things out enough - why does the
>main "rules.cml" file have architecture-specific info, for example?
>
>That's a big step backwards as far as I'm concerned - we didn't use to
>have those stupid global files, and each architecture could do it's own
>config rules. Eric never got the point that to me, modularity is _the_
>most important thing for maintenance.
>
>Something I also asked for the config system at least a year ago was to
>have Configure.help split up. Never happened. It's still one large ugly
>file. Driver or architecture maintainers still can't just change _their_
>small fragment, they have to touch a global file that they don't "own".
>
>So if somebody really wants to help this, make scripts that generate
>config files AND Configure.help files from a distributed set. And once you
>do that, you could even imagine creating the old-style config files
>(without the automatic checking and losing some information) from the
>information.
>
If you go thus far... then I think, that the Configure.help stuff should
be embedded inside the driver source code
itself. Like for example the postfix MTA code is embedding whole *man*
pages there. And *man* pages would be
anyway a more appriopriate and classical place where the current
Configure.help information should be.
Just lift the code over from there (The extraction is even proper awk
insead of some perl crap...) and be nearly done.
-
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/