Re: Build systems suck. Can Lua be the basis for a better build system?

[Sean Conner <sean@...>]

It was thus said that the Great Spencer Parkin once stated:
> 
> That's it, right?  What else does a build system have to be?  There are
> quite a few details to be worked out about handling a file-system, but does
> it have to be anymore complicated than all this?  I'm tempted to let any
> file-system details be left entirely to the user so that the build system
> doesn't even know what a file is.  Extension of the core build system could
> add support for all that.  The build system should be as small and
> light-weight as possible.
> 
> So now what about implementation?  A few ideas...

  I've been thinking along these lines over the past week or so (and also
back in 2009 as I go through some directories).  I did come up with the
following (for a simple project I wrote a few years ago):
	
	_LANG	= "C"	-- default to C, ".c" ".o" or ".obj", etc
	CC      = "gcc -std=c99"
	CFLAGS  = "-g -Wall -Wextra -pedantic"
	LDFLAGS = "-g"
	
	_DEFAULT = "se"
	
	se     = { 'ansi-c', 'se-cmd', 'se-impl' }
	linux  = { 'linux', 'se-cmd', 'se-impl', 'se-extc', 'se-exti' }
	sample = { 'sample', 'se-cmd', 'se-impl', 'se-extc', 'se-exti' }

Because this is based on C, the *actual* dependencies as calculated by the
program would be (using "make" syntax here):

	se : ansi-c.o se-cmd.o se-impl.o
	linux : linux.o se-cmd.o se-impl.o se-extc.o se-exti.o
	sample : sample.o se-cmd.o se-impl.o se-extc.o se-exti.o

	ansi-c.o : ansi-c.c se.h
	se-cmd.o : se-cmd.c se.h
	se-impl.o : se-impl.c se.h
	linux.o : linux.c se.h
	se-extc.o : se-extc.c se.h
	se-exti.o : se-exti.c se.h
	sample.o : sample.c se.h

	(dependencies for .C files were generated automatically, with
	some prunning)

  As it stands right now, it outputs a makefile; variables that do not start
with a "_" and are strings are output verbatum; variables that are tables
become the rules to make the files; variables that start with "_" are for
the Lua program itself and are not passed on to the makefile (but they do
influence how the makefile is made).

  Another example (hmmm ... I'm translating this from my 2009 musings and
already I see an issue; I can work around it here but as you'll see, it's
ugly):

	LDLIBS = { "fl" }

	rt = { 'lex.yy' }
	_G['lex.yy.c'] = 
	{ 
	  'racter.translate.flex',
	  _CMD = "flex $@ $<"
	}

  This will generate:

	LDLIBS = -lfl
	rt : lex.yy.o
		$(CC) $(LFLAGS) -o $@ $^ $(LDLIBS)

	lex.yy.o : lex.yy.c
	lex.yy.c : racter.translate.flex
		flex $@ $<

  I used make as a backend, because at this stage, I'm more playing around
with syntax and what not.  I started work on including other "mkfiles" (as
I'm calling them), with automatic filename modification, so including a
mkfile in a subdirectory will adjust the filenames (if that makes sense).  I
have yet to finish this particular feature.

  -spc (But like I said elsewhere, I keep going back to make ... )