Mk: A Successor to Make (1987) [pdf]

Post by Zambyte » Sun, Jul 16, 2023, 11:11 PM UTC

kdmccormick wrote: post #31

duped wrote: post #30

Earlier quoted context omitted.

Programs are just DAGS with syntactic sugar

Not sure I follow. 0001 GOTO 0002 0002 GOTO 0001 How would that be a DAG?

    (begin
        (0001 GOTO 0002)
        (0002 GOTO 0001))

Post by rollcat » Sun, Jul 16, 2023, 11:18 PM UTC

mananaysiempre wrote: post #4

jylam wrote: post #3

Funny how building tools are reinvented again and again, with all the same culprits. I'm a programmer since the mid-90's, there are countless tools to do the job, and they are just as cumbersome and complicated the more they evolve. I'm personally sticking to the good old configure/make for my own C projects, but I understand that's a matter of taste and habits. I've written some CMakeLists.txt from time to time, any…

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…

Post by rollcat » Sun, Jul 16, 2023, 11:26 PM UTC

nemetroid wrote: post #28

vimax wrote: post #24

Earlier quoted context omitted.

I agree with you about that statement, but why don’t you commit to an unstable branch? Why risk losing something or pass up having a better development history?

The way the warning is worded suggests that any invocation of tup has a risk of deleting your files, implying that to be entirely safe you should commit before every single build , which would be ludicrous.

Post by nsajko » Mon, Jul 17, 2023, 1:24 AM UTC

wahern wrote: post #27

throwawaaarrgh wrote: post #14

It 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.

Post by ggm » Mon, Jul 17, 2023, 1:42 AM UTC

nsajko wrote: post #39

gigatexal wrote: post #26

I like the simplified syntax of this mk, anyone know why it didn't catch on?

Research Unix wasn't easily available, AFAIK Bell Labs were trying to sell it as a product, so it lost to more free alternatives. It only got open-sourced recently AFAIK, years after being abandoned.