Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

doc.cat-v.org

Post reply on HN
Print view View original

1–10 of 54 posts

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

#3

Post by jylam »

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, anything you want to do requires some digging in some sort of stackoverflow answers (thanks to those who answer) for "not so common but yet I need them" weird features.

I'm not criticizing anyone or any tool, just that we can't seem to find some good way to tool the compilation of both trivial and very complex projects, without taking an hour or two off.

I also understand that I do not want to work on such an endeavor, that seems boring AF and kudos for people that like that. You are not enough it seem :)

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

#4

Post by mananaysiempre »

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 inherits from rc the principle of having the list of strings as the fundamental datatype (also used by Jam). That works, but it’s noticeably more limiting than Tcl’s route of having everything be strings but with robust quoting and unquoting procedures for putting lists inside them—at which point Tcl starts to look like a Lisp-2 with a slight propensity for stringiness and a mildly unusual syntax.

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

#5

Post by mort96 »

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…

Ohhh, passing variables as env vars is a good idea. That means things like "$foo" in a recipe just works even if 'foo' contains quotes.

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

#7

Post by jacobvosmaer »

vmsp wrote: post #2

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

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

#10

Post by DanHulton »

TheLocehiliosan wrote: post #6

An alternative I quite like is “just”. https://github.com/casey/just

Was going to mention this. I've recently started converting my Makefiles to justfiles, and it's just nicer. Even being able to inline scripts to clean up "loose" files is a big win.
Post reply on HN