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

21–30 of 54 posts

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

#21

Post by klysm »

chriswarbo wrote: post #16
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…

Nix represents its builds in a way that's similar: each "derivation" is a text file like /nix/store/XXXXXXX-foo.drv, where XXXXXX is a hash of that file's content. This way each file can reference any others by their path, and there can never be cycles (unless we brute-forced SHA256 to find a pair of files which contain each others hashes!). This uses of hashing requires the files to be immutable, but that's good for…

I didn’t realize that content addressing girls like that prevented circular deps by construction (with very high probability). That’s a super cool property to get as a bonus

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

#22

Post by zokier »

packetlost wrote: post #11
TheLocehiliosan wrote: post #6

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

Just isn't really a replacement for make outside of the "simple command/task runner". Make is really a lot more powerful and has things like files system driven dependency handling.

Of course that is the whole point of just, to be simpler and more focused tool because a task runner is what people commonly want and the bloat/complexity of make is more of hindrance. This is clearly mentioned in the readme too

> just has a ton of useful features, and many improvements over make:

> • just is a command runner, not a build system, so it avoids much of make's complexity and idiosyncrasies. No need for .PHONY recipes!

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

#24

Post by vimax »

nmz wrote: post #15
imran-iq wrote: post #12

Earlier quoted context omitted.

There's also tup: https://gittup.org/tup/

From https://gittup.org/tup/getting_started.html > Make sure your source files are backed up, like in source control, or something. Tup is able to delete old files automatically, though it tries to prevent you from doing silly things like overwrite your hand-written C files. Still, it would suck if you got boned because tup has a bug or something. Hey, your hard disk can go at anytime, too. This is unacceptable, no t…

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?

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

#25

Post by mananaysiempre »

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…

> It seems to me that all build systems are just DAGs with syntactic sugar and functions.

True in the broadest sense, but there are choices to be done regarding the possibility of discovering what the graph is or has become on the fly and the propagation directions. See “Build systems à la carte”[1,2] for a systematic exploration.

(See also a neighbouring comment[3] re how the discourse structure[4] of the build script might be important in a way orthogonal to these execution-engine issues. The boundary between the build system and the build tool proper can be drawn in very different places here.)

[1] https://dx.doi.org/10.1145/3236774

[2] https://youtu.be/BQVT6wiwCxM

[3] https://news.ycombinator.com/item?id=36749885

[4] https://brenocon.com/blog/2009/09/dont-mawk-awk-the-fastest-...

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

#27

Post by wahern »

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.

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

#28

Post by nemetroid »

vimax wrote: post #24
nmz wrote: post #15

Earlier quoted context omitted.

From https://gittup.org/tup/getting_started.html > Make sure your source files are backed up, like in source control, or something. Tup is able to delete old files automatically, though it tries to prevent you from doing silly things like overwrite your hand-written C files. Still, it would suck if you got boned because tup has a bug or something. Hey, your hard disk can go at anytime, too. This is unacceptable, no t…

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.

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

#29

Post by [deleted] »

vimax wrote: post #24
nmz wrote: post #15

Earlier quoted context omitted.

From https://gittup.org/tup/getting_started.html > Make sure your source files are backed up, like in source control, or something. Tup is able to delete old files automatically, though it tries to prevent you from doing silly things like overwrite your hand-written C files. Still, it would suck if you got boned because tup has a bug or something. Hey, your hard disk can go at anytime, too. This is unacceptable, no t…

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?

[deleted]

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

#30

Post by duped »

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…

Programs are just DAGS with syntactic sugar
Post reply on HN