writing (Gnu)MAKE in Python

[Donn Cave]

Quoth "John Schmitt" <jschmitt at vmlabs.com>:
| I'd love to take the diversion of writing Make using Python.  The things
| that are keeping me from doing this are, in order:
|
| - I'm not completely convinced that doing this is a good thing
| - my employer has not asked me to, and I doubt they would see the value in
| it that I do
| - Make is big and complicated and reproducing all the functionality that we
| need (complete with quirks and bugs) would be time-consuming
| - if I couldn't demonstrate its value immediately the work would not be
| appreciated, especially since we have many other projects worthy of my time
|
| The benefits as I see them (in no order):
|
| - provide a Make that really, really works
| - Make would work the same everywhere!  wouldn't that be great?!
| - not only would Make work the same way everywhere, it would take care of
| foreslash and backslash differences too!
| - Make bugs would be easier to fix
| - new features would be much easier to add
| - if I got it into our tool set, just maybe, Python will be accepted as a
| (preferred?:-) development tool
| - if I did it, it would be my opportunity to learn Python and to learn Make
| fairly well
| - did I mention portability?

You must have a more detailed notion of a ``Make that really, really
works''.  If it's just another implementation, I'd give you slim odds,
against the ``make is big and complicated'' point you allude to above.
But there might a be a good chance for a radically different solution
to the basic problem.  OOP is an obvious fit.  The two step, configure
and make strategy that's common today is an obvious target for replacement.

The sad thing is that the Python distribution itself would be the last
place we could use this system.

| In a smaller way, I would like to have Bash, sed, and grep as Python
| programs rather than compiled C.

I think you're alone on that one.

	Donn Cave, donn at oz.net