To add to the pile of task runners here, I made this one: https://code.ofvlad.xyz/v/lightning-runner . I like it, and currently use it for all personal projects. Mainly, posting here for some feedback!
Mk: A Successor to Make (1987) [pdf]
41–50 of 54 posts
Re: Mk: A Successor to Make (1987) [pdf]
#42To add to the pile of task runners here, I made this one: https://code.ofvlad.xyz/v/lightning-runner . I like it, and currently use it for all personal projects. Mainly, posting here for some feedback!
[deleted]
Re: Mk: A Successor to Make (1987) [pdf]
#43I own a couple books on Make and it's a great tool, but I learned how to use Mk by just reading the manpage. It's a huge improvement and simplification at the same time.
There's a solid, stand-alone implementation of mk in golang. No plan9 environment needed.
Re: Mk: A Successor to Make (1987) [pdf]
#44For those curious, Mk is available in Plan 9 from User Space https://9fans.github.io/plan9port/
I tried plan9port's mk for a moment out of curiosity. I quickly ran into an annoying usability problem: it compares file mtimes with second accuracy. https://github.com/9fans/plan9port/blob/cc4571fec67407652b03... With sub-second build times for individual targets, this causes mk to needlessly recompile files because the target may have the same mtime as the prerequisites.
That looks like it would be relatively straightforward to fix. Attempted nerd snipe?
Re: Mk: A Successor to Make (1987) [pdf]
#45It seems to me that all build systems are just DAGs with syntactic sugar and functions. You could do away with build systems entirely if there were some Unix commands that manage an arbitrary DAG, where the state is kept out of band (in a file, in a database, etc) so you can operate on the DAG from any process. That way the shell (or any program, really) becomes your build system and you can compose any kind of logic…
> if there were some Unix commands that manage an arbitrary DAG There is: tsort. It's a POSIX utility, even, not just a GNU or BSD utility.
Wow, that's awesome!
Re: Mk: A Successor to Make (1987) [pdf]
#46It seems to me that all build systems are just DAGs with syntactic sugar and functions. You could do away with build systems entirely if there were some Unix commands that manage an arbitrary DAG, where the state is kept out of band (in a file, in a database, etc) so you can operate on the DAG from any process. That way the shell (or any program, really) becomes your build system and you can compose any kind of logic…
There are a few more components. In particular, how the build system decides what needs to be done, and how tasks are ordered, are significant. For an excellent synthesis of what Makes a build system, I can't recommend the 2018 paper "Build Systems A La Carte" enough: https://www.microsoft.com/en-us/research/uploads/prod/2018/0... By Andrey Mokhov, Neil Mitchell (now working at Meta on the Buck2 build system) and Sim…
oh, and Andrey Mokhov since works at Jane Street on the build system Dune:
Re: Mk: A Successor to Make (1987) [pdf]
#47Earlier quoted context omitted.
Not sure I follow. 0001 GOTO 0002 0002 GOTO 0001 How would that be a DAG?
More of just a graph like: V: (0001, 0002) E: ([0001, 0002], [0002, 0001]) But really I was just being sarcastic. Builds are "just" DAGs with syntactic sugar just like programs are "just" DAGs with syntactic sugar. That's one possible abstraction and one that is inherently lossy, because what "sugar" is available is the actual meat that makes one build system useful and another terrible. And one actually awful limita…
Right, I understand the graph metaphor, my objection is that programs in a turing complete language do not seem like they can exhaustively modeled as DAGs. Graphs, sure; but AFAICT DAGs fail due to the halting problem (in some abstract sense).
A build system modelling itself as a DAG, on the other hand, is very consciously taking on acyclicity as a feature.
I am curious what builds would need to be cyclic. Artifact A is built from B and C, where C is built from D and A? Does that happen in any well-designed build?
Re: Mk: A Successor to Make (1987) [pdf]
#48Earlier quoted context omitted.
Not sure I follow. 0001 GOTO 0002 0002 GOTO 0001 How would that be a DAG?
I think they meant more the syntactic representation, rather than the control flow. If you rewrite the program using s-expressions, the DAG becomes a little more clear (begin (0001 GOTO 0002) (0002 GOTO 0001)) The DAG has two branches, each with three leaves. There are no cycles in the syntax, even if there is in the execution.
Sure, but I would imagine that GGP would have said been more specific and said "tree" instead of "DAG" if they were talking about the AST.
Re: Mk: A Successor to Make (1987) [pdf]
#49Earlier quoted context omitted.
Plan 9’s mk isn’t really a radical departure from Make, it is more of an adaptation of it to the (decidedly non-POSIX) Plan 9 shell, rc, with modest extensions. One design mistake in make that mk fixes is variables in recipes: those are now passed as environment variables, with no prior substitution, so no more writing $$$$ to get the current PID in a recipe (and it’s written $pid in rc anyway). Unfortunately, mk inh…
Both Mk and Rc started out with Research Unix, some years before Plan 9.
I've been seeing people, never ones who were actually there, make this claim in the last five to ten years. Rc was on tenth edition Unix. I've seen no evidence that it originated on Unix. The manual calls it the Plan 9 shell.
Re: Mk: A Successor to Make (1987) [pdf]
#50It seems to me that all build systems are just DAGs with syntactic sugar and functions. You could do away with build systems entirely if there were some Unix commands that manage an arbitrary DAG, where the state is kept out of band (in a file, in a database, etc) so you can operate on the DAG from any process. That way the shell (or any program, really) becomes your build system and you can compose any kind of logic…
Mash from Inferno
https://inbox.vuxu.org/9fans/AANLkTikvTbqLwrxifri86cAEBS3wmk...