lkml.org 
[lkml]   [2001]   [Dec]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 13:14    [W:6.619 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site