Re: Regarding "make"-systems [Was: Re: [dev] Build system: redo]

From: Connor Lane Smith <cls_AT_lubutu.com>
Date: Sun, 12 Aug 2012 00:17:35 +0100

I'm going to ignore the "dogma" subthread, because, Christ.

On 10 August 2012 11:35, Connor Lane Smith <cls_AT_lubutu.com> wrote:
> These are quite easy to fix; we'd have to play around with the syntax
> and come up with our own. But I would definitely like a tool that
> solves (C) and only (C). (D) follows trivially.

So I've been thinking a little about this problem, and I came to some
conclusions. In reverse order...

(D) We would have a process which reads the depfile and waits for
input. We would have another process which decides which files have
changed, and pipes them to the first process. Reading these files, the
first process would print the appropriate commands; this goes into
sh(1), which does what it does best.

(C) Do we actually need a dependency graph? The way I see it, all we
need is a single level: if this changes, do this. That's it. No rule
"targets"; if a file is changed during the build the second process
will pick that up and pipe them too.

(B) The "DSL" should probably amount to
"[[files...][\n\tcommands...]\n...]". First is default.

(A) This suggests that we need a macro system. cpp(1) would bring us
#define, #ifdefs, and #include for free. This is good, because it
means we don't need to invent our own whole scripting subsystem.

So all we'd need is for something to parse the extremely simple file
format and act as a lookup table given [[files...]\n...], and
something to watch for changes (first by timestamp and then, e.g.,
with inotify) and print them. Shouldn't be more than a couple hundred
lines of C with a little shell glue. Should be pretty nippy, too.

cls
Received on Sun Aug 12 2012 - 01:17:35 CEST