Re: proposal to fork the build-tools projects

[Tom Lord]

Also in defence of the `sh + make' approach:

GNU make can do lots of useful globbing and set manipulation of file
lists.

It therefore encourages a pretty simple-minded approach to source tree
organization, where files are grouped into directories and named
according to how they fit into the build process.  If you do things
right, your Makefiles don't need to contain specific filenames at all,
and you don't need to edit any Makefiles as you add, delete, or rename
files -- you just move things around more or less freely, and the
build-process catches up more or less automatically.  The net effect
of imposing that simple-minded naming and organizing discipline on the
build system, is that refactoring code, experimenting with new files,
and so forth all becomes much _easier_ (perhaps surpsrisingly).

So if you say "Well, I'm going to make build tools in Scheme or
Python, because I want a full-powered programming language for them,"
oddly enough, I'm skeptical.   The pay-off for build-tools with
limited interpreted capabilities is that source trees management
becomes more ...uh... "fluid".  It becomes flexible without being
difficult to think about.

Don't get me wrong.  I think the idea of switching to a better
implementation language is swell.  But I'm to the point where, if I
were going to make build-tools in Scheme, say, the approach I would
take would be to make lots of very restricted "tiny languages",
implemented in Scheme.  I could very easily wind up back very close to
`sh + make + awk + ...'.  And then I'd consider adding domain-specific
syntaxes at points...

I'm therefore not sure it's a really high priority to bother: GNU
make, for example, seems like a quite tractable little program in an
implementation that's well suited to make run really fast (and that
can be compiled in a very minimal environment).  By using it, rather
than trying to re-build it in Python, you're buying into the GNU
make maintainers' opinion about what "tiny language" affords a
tractable, portable implementation with few dependencies.

Having said all of that, I still think that having to generate shell
scripts from m4 input is a pain in the neck, with a payoff
(portability to messed up shells) that is only relevant to a very
small, fixed number of packages.  Fork the m4-ish, generic make-ish
version for those packages, keep it stable, and move on from there (is
what I'm "proposing").

If you are content to have a fork that requires a proper shell and
GNU make, I think you could do worse than to adopt the general
approach and layout of `package-framework'.

-t