Re: [KBUILD] Re: Announcing CML2, a replacement for the kbuild system

From: Peter Samuelson (peter@cadcamlab.org)
Date: Wed May 24 2000 - 21:18:52 EST


  [esr]
> > Basically, because managing memory by hand for this kind of
> > application is more pain than I want to go through. And the
> > resulting program in C would be far more complex and bug-prone.

[willy@thepuffingroup.com <willy@thepuffingroup.com>]
> why even bother keeping track of memory? this is a run-and-exit
> program; the memory you used gets freed at exit.

If it really turns out to be that simple, someone can go and rewrite
the whole business in C. (You know, like ksymoops.) When Eric first
brought his proposal to linux-kbuild a few months ago, we made him
promise to draft a full language spec (as opposed to just a RTSL spec).
This is one reason -- so it can be reimplemented accurately.

In fact, depending on how well I end up liking his language (haven't
downloaded it yet, but I remember roughly what it looked like in
earlier design stages -- it did seem sane) I might take this on myself.
Because I don't know if I want to see the extra tool requirement. And
I *really* don't think I want to see "freeze" files in Linus's patches.
(Precompiled files are, unfortunately, *necessary* with SCSI firmware
... they shouldn't be necessary in the config system.)

Peter

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:13 EST