Re: Announcing CML2, a replacement for the kbuild system

From: david parsons (
Date: Sat Jun 03 2000 - 14:00:39 EST

In article <linux.kernel.20000603154538.B28004@ummagumma>,
Tom Gilbert <> wrote:
>* Jonathan Walther ( wrote:
>> Using Python isn't the kind of "laughing in the face of danger" they
>> admire. After all, Python is a wimpy fru-fru Object Oriented language;
>> no self respecting kernel he-man would lower himself to rely on
>> one of THOSE to compile his kernel. No sirree bob, its gotta be
>> C and gmake all the way, with possibly a bit of bash and tcl
>> thrown in.
>Urm. Since when was the philosophy of this group "use an inappropriate
>tool for the job because that's what Real Men Do"?

    It depends on what the job is.

    If the job is ``wedge Python into the kernel so it can be used as
    advertising against Perl'', then, yes, Python is the ideal tool
    for the job.

    If the job is ``clean up the kernel configuration process'', then
    it's not so clear that Python is appropriate. I am using (and
    hacking as needed) a variant of mec's mconfig tool, and it is *very*
    good about properly reporting bugs in the kernel configuration
    scripts, and it has the decided advantages that it's written in C, it
    doesn't use anything fancier than ncurses (which is already used by
    menuconfig, and it's _very_ likely that you'll find ncurses as a
    standard component on a Linux distribution), and it doesn't break
    the entire universe and replace it with a new one that has the
    reference implementation in some horrid little scripting language.

    david parsons \bi/ I suspect that mconfig would work with real curses,
                   \/ but, alas, I don't have many copies of that around.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:17 EST