Hacker News Reader

Comment by jylam | Hacker News Reader

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 :)

View on HN

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.

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.

Actually it doesn't really solve the $$foo problem. If your make target has an inline shell script with a variable reference, is it referring to a make variable or a shell variable? Is it set in make? If not, what will make do with that variable reference in the inline shell - nothing? Make it an empty string? Keep the literal '$foo' string? And what if both make and inline script have the variable set but they need to be different?

It does solve the $$foo problem in that mk just doesn’t do any variable substitution in recipes, at all. For each invocation of a recipe, it adds the values of mk variables it has computed to the parent environment, then execs a shell and passes it the entire recipe verbatim.

> at which point Tcl starts to look like a Lisp-2 with a slight propensity for stringiness and a mildly unusual syntax.

I always saw Tcl as a bastard child of Lisp and sh. It's beautiful in its own quirky way.

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.

I was going by the fact that tenth edition Unix was released on 1989, while Plan 9 was first released in 1992: https://en.wikipedia.org/wiki/Research_Unix

Pehaps this is misleading.

Some clues:

The mk paper (and Unix man page) doesn't mention rc.

Plan 9 existed since the mid-80s.

This sentence in the Unix rc(1) sure makes it seem like rc was Plan 9-first:

Environment entries for variables are kludgy for UNIX compatibility.

The first paragraph of https://archive.org/details/rc-shell/

So rc was made for Plan 9. The examples in that paper are definitely on tenth edition Unix, I think this would be because

A fairly complete version of Plan 9 was built in 1987 and 1988, but development was abandoned. In May of 1989 work was begun on a completely new system

from https://doc.cat-v.org/plan_9/1st_edition/designing_plan_9 (1990).

Reply on news.ycombinator.com