lkml.org 
[lkml]   [2001]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [kbuild-devel] Re: CML2 design philosophy heads-up
    Alan Cox <alan@lxorguk.ukuu.org.uk>:
    > > In general this is the best option, if you create a non-standard
    > > configuration for machine foo then it is your problem, not everybody
    > > else's.
    >
    > Which makes CML2 inferior to CML1 again. Now if it could parse CML1 rulesets
    > this whole discussion wouldn't be needed.

    I think you're confusing a couple of different issues here, Alan. Even
    supposing CML2 could parse CML1 rulesets, the design question about how
    configuration *should* work (that is, what kind of user experience we
    want to create and who we optimize ruleset design for) wouldn't go away.

    I'm raising these questions now because CML2's capabilities invite
    thinking about them. But they're independent of the underlying language.
    --
    <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

    To stay young requires the unceasing cultivation of the ability to
    unlearn old falsehoods.
    -- Lazarus Long
    -
    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 12:53    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean