writing (Gnu)MAKE in Python

[John Schmitt]

> -----Original Message-----
> From: python-list-admin at python.org
> [mailto:python-list-admin at python.org]On Behalf Of Donn Cave
> Sent: Sunday, June 18, 2000 9:56 AM
> To: python-list at python.org
> Subject: Re: writing (Gnu)MAKE in Python
>
>
> Quoth "John Schmitt" <jschmitt at vmlabs.com>:
> [deletia]
> You must have a more detailed notion of a ``Make that really, really

Sure do.  Example: I did this in a Makefile (and the manual says that it's
valid):

foo: DEFINES += -DFOOBARBAZ

and it did not work.  I downloaded the source, but it would have taken me
too much time to dive in and fix it.

Another example, something like this:

bar:
	$(MAKE) $(MAKEFLAGS) -C bar bartarget

and Make crapped out with "There's no folder 'W'".  I looked at it, and Make
did not put the dash character in front of the 'W' character, and so instead
CDing to my 'bar' directory, it was trying to CD to my 'W' directory (which
obviously did not exist).  The equally dumb hacks and workarounds that I
came up with took less time than diving into the Make source code and
looking for the bug there.

> 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.

I'm sorry, I don't understand what you mean here.

> 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.

Me personally, I would love a radically different solution (provided of
course that it is also a productive solution).  Getting it adopted where I
work requires a very compelling case, and I don't understand everyone else's
project enough to be able to duplicate it with other build tools and so
selling another solution is difficult for me.

My personal philosophy is to try to stay unattached to any particular
methodology, tool, habit but to always be open to improvements.  I cannot,
in that endeavor, forget who I'm working for and what their needs are.  IOW,
I love to play, but I have work to do.  If the play improves productivity
and I can demonstrate it, I am so there.  I have worked with people who
behaved in a very 'stick-in-the-mud' way to know that I don't want to get as
stale as they did.

Anyway, how is OOP an obvious fit to this problem in general?  Not obvious
to me.  The general idea of make seems pretty good to me, but as I just
learned, it's being applied to problems I don't understand very well.

>
> 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.

Again, I'm not being very clear.  It is not my end goal to have Unix command
tools written in Python rather than compiled C.  I would prefer them as
Python tools because IMHO there would be fewer bugs and maintenance hassles,
bugs would be fixed more often, and it would be *much* easier to port to
other platforms.  Even more, when someone comes up with a new way to extend
a tool, it's so much easier to put it in and try it out.  I guess that I
believe that advancements will happen much faster if these tools were
distributed as Python modules rather  as binaries of C code.  Debate about
advancements (specifically the lack thereof) in tools is best left
elsewhere, I suppose.

John

PS Is 'deletia' a word?  http://www.m-w.com/ does not have a definition for
it but 'deletia' is meaningful to me.