Messages in this thread | | | Date | Fri, 28 Dec 2001 19:08:54 +0000 (GMT) | From | Riley Williams <> | Subject | Re: State of the new config & build system |
| |
Hi Linus.
> [ 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;]
I had wondered where he'd gone to - Jeff was one of the few from who I read every email, and it's been a while since I saw anything from him.
> 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.
I offered to go through Configure.help and split it up a while back, and I was drowned in several dozen emails saying that such was a BAD THING, with absolutely zilch saying otherwise. I'm more than willing to have a go at splitting it up into separate files by directory, but before I do, I would need to know how you wished to deal with symbols that are referenced all over the source tree rather than just in a single directory.
Another thing I'd like to do is to introduce a "boilerplate" mechanism whereby help text that's repeated in multiple options gets stored just once and dragged in when it's needed. I've made a start on doing that with the current Configure.help file and the `make config` and `make menuconfig` commands, and have patches available against the 2.0.39, 2.2.20 and 2.4.17 trees to provide the base implementation for `make config` but gather that such is pointless as those commands will soon be extracted from the Linux kernel.
Best wishes from Riley.
- 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/
| |