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

[William Ahern <william@...>]

On Sun, Mar 10, 2013 at 10:04:12PM -0400, Sean Conner wrote:
> It was thus said that the Great William Ahern once stated:
> > 
> > Sorry for the OT, but this scenario is actually more representative than you
> > might think. "System" headers are anything included by "<...>", including
> > third-party libraries. If you update to a newer version of Lua, or update an
> > XML library, then your dependencies are already out-of-date when you next
> > `make`, and ideally make would know this and rebuild stuff that depended on
> > those headers.
> 
>   But then you'll need to generate the dependencies at compile time (or at
> least at installing the source time), because where is math.h stored?  On
> Unix systems, it's most likely in "/usr/include" but on Windows?  

That's why compilers, at least on Unix, have options to generate
dependencies, and they even emit them in Makefile syntax so they can written
to a file and source-included. This is the origin of the `make dep` or `make
deps` build target that used to be very common. (Most people today either
don't bother, or generate them at runtime.)

For GCC and clang it's -M, for SunPro it's -xM. Intel, IBM, HP, etc.
compilers all have similar compiler switches (usually -M or similar). The
BSDs have mkdep(1), which these days is just a wrapper around `gcc -M'.

So, for example, if you have a source file, foo.c, which just includes
<math.h> then on OS X `gcc -M foo.c` produces

foo.o: foo.c /usr/include/math.h /usr/include/sys/cdefs.h \
  /usr/include/sys/_symbol_aliasing.h \
  /usr/include/sys/_posix_availability.h /usr/include/Availability.h \
  /usr/include/AvailabilityInternal.h

Compilers usually also have options to ignore system dependencies, so you're
free decide whether you really want to depend on external includes or just
your local application includes. So, for example, `gcc -MM foo.c` produces

foo.o: foo.c

This works best w/ GNU Make because include paths are treated like any other
target. So you can generate dependencies in the first instance dynamically,
like

DEPS=$(OBJS:.o=.d)

%.d: %.c
	(printf "$@ " && $(CC) -M $(CPPFLAGS) $<) >| $@ || rm $@

ifneq ($(MAKECMDGOALS),clean)
-include $(DEPS)
endif