Re: lua-l Digest, Vol 38, Issue 74

[Sean Conner <sean@...>]

It was thus said that the Great John Hind once stated:
> 
> As for make files, declarative or whatever, what the hell is wrong with
> procedural? Building *is* a procedure after all! Just use Lua (with a
> suitable toolkit library), do not make us learn something else!

  The main reason for Makefiles being declarative rather than procedural is
to enable the computer to make certain optimizations that it couldn't with 
procedural directions.

  All a Makefile is, is a series of targets, their depenencies, and how to
make the target.  So, a simple Makefile:

	a : a.o b.o c.o d.o
		$(CC) $(LDFLAGS) -o $@ $^ $(LDLIBS)

	a.o : a.c a.h b.h c.h d.h
		$(CC) $(CFLAGS) -c -o $@ $<

	b.o : b.c a.h b.h
		$(CC) $(CFLAGS) -c -o $@ $<

	c.o : c.c c.h
		$(CC) $(CFLAGS) -c -o $@ $<

	d.o : d.c d.h
		$(CC) $(CFLAGS) -c -o $@ $<


	NOTE:  $(CC), $(CFLAGS), $(LDFLAGS) and $(LDLIBS) define the
	compiler and various options passed to the compiler.

	$@ is replaced with the target
	$^ is replaced with all the dependencies
	$< is replaced with the first dependency

sets up a depenecy graph of the project.  To build a, you need a.o, b.o, c.o
and d.o, and so on down the line.  From a clean start, then yes, everything
is built.  What order, well ... a will be the last thing built, but the test
can pretty much happen in any order, so it might be built:

	1. a.o
	2. b.o
	3. c.o
	4. d.o
	5. a

  But I have a four core system at work, and this means that make is now
free to do it:

	1. a.o b.o c.o d.o
	2  a

that is---since I have four cores, I can build the object files at once (one
per core) for a significant speed up.  The other side effect is that make
can now do the minimum amount of work---if I change d.c, then rebuild, the
steps are:

	1. d.o
	2. a

(this can't be parallelized because a depends on d.o, but that's okay, since
only d.c changed, we just need to recreate d.o and then a)

  The major problem with writing a Makefile is actually figuring out all the
depenencies.  There are a few tools to help, but I've found them to be
hit-or-miss and generally, not worth the time (IMHO).

> The Lua source code is brilliantly written and genuinely portable without
> editing - using an Eclypse based IDE I even (quite easily) got it compiled
> and running on a ARM microcontroller (before discovering that there was not
> enough RAM to do anything useful!). Sadly third party libraries aren't
> always so straightforward (in many cases there are good reasons for that).
> My plea to library authors: learn from the Lua code base, pull out one of
> the built-in libraries and use it as a template for your code.
> If you run into a problem, look through the Lua code base - the Lua guys
> probably faced and solved the same problem at some stage and you can bank on
> their solution being portable.

  Which is fine, until you want to do something outside the scope of ANSI C
(like, walking a directory, or displaying a window).  

  -spc (And yes, anybody can write APL in any language 8-P