walk

Not impressed by shell incantations. What would sell such a tool to me is a feature to replace those with new and more intuitive syntax. And a terser one, too. Holding on to how things are done in the shell is not a thing to be proud of. I think a lot of us around here stopped counting the times we got tripped by globbing, forgetting or misplacing one special character in a ${} block, or quoting. Let those monstrosities die already. Please. There's this tool -- https://github.com/ejholmes/walk -- that is pretty good and I liked it but dropped it for the same reasons: it leaves the heavy lifting to you and it depends on your mastery in the black arts. Now obviously I'm not managing huge projects but nowadays https://github.com/casey/just serves me just fine for everything I need.

Check out walk[1]. It does exactly this. Lets you define a graph of dependencies in any language of your choice. [1](https://github.com/ejholmes/walk/)

My colleague @ejholmes wrote a cool tool that borrows heavily from `make` called `walk` (https://github.com/ejholmes/walk). It's written in Go and using a graph for dependencies so that tasks at the same horizontal level in the graph may be run at the same time. We use this at remind.com to significantly speed up our multi later AMI build times.

https://github.com/ejholmes/walk can do most of this FWIW.

Good question. It's not a concern of walk(1) itself, since it's impossible to generalize for every use case. walk(1) _always_ executes the target, but the target itself can decide whether it actually needs to do work. For a C project, you would just do something like this: https://github.com/ejholmes/walk/blob/master/test/111-compil.... That's a trivial example using mtime. You could replace it with a hash function if you wanted.

A true build system really needs to build out a DAG of dependencies to be efficient and fast. Compose this with https://github.com/ejholmes/walk and you're good.

> As a shameless plug, I built a tool similar to Make and redo […] https://github.com/ejholmes/walk Your README’s example show `parse.h` as output from `Walkfile deps parse.o`, I think that is a mistake. As for your build system (and comment), I have some questions: 1. How do you achieve using a deterministic hash as condition (and aren’t all hash functions deterministic)? 2. Why would you not be able to use mtime as a dependency? The only case I have run into is when the build depend on data from remote machines, but in that case, I think the proper solution is to have an initial “configure” step where you retrieve the data your build depend on and/or a build rule to update this data. 3. Does your build system execute the Walkfile for every node in the graph on each walk? Because that sounds like a quite noticeable overhead for larger p

Make's underlying design is great (it builds a DAG of dependencies, which allows for parallel walking of the graph), but there's a number of practical problems that make it a royal pain to use as a generic build system: 1. Using make in a CI system doesn't really work, because of the way it handles conditional building based on mtime. Sometimes you just don't want the condition to be based on mtime, but rather a deterministic hash, or something else entirely. 2. Make is _really_ hard to use to try to compose a large build system from small re-usable steps. If you try to break it up into multiple Makefiles, you lose all of the benefits of a single connected graph. Read the article about why recursive make is harmful: http://aegis.sourceforge.net/auug97.pdf 3. Let's be honest, nobody really wants to learn Makefile syntax. As a shameless plu