I'm going to ignore the "dogma" subthread, because, Christ. On 10 August 2012 11:35, Connor Lane Smith <c...@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
