I seriously wonder if the author ever worked on a project with more than around 10k LOC, multiple languages and tools, automatic testing, deployment, version control (merging this build script is going to be a huge PITA).
No, you have to realize you're working on one side of the graph (source code), but your build produces something on the other side (your artifact). Without automatic dependency resolution of you DAG, you're constantly traversing from one side to the other, making the build 'work'.
I applaud the effort, but is "pure /bin/sh" really a good feature in today's systems?
To my knowledge, today every Unix system has Python, usually at least 2.7, if not Python 3. Some even replaced most of their system shell scripts with Python scripts. (Formerly, Perl had this status, but never really caught on in that area.)
Python is a much cleaner language than any shell language, especially with regard to error handling. (yes, I'm aware of "set -eu") Also, if you occationally need some more elaborated data structures or algorithms, you can express these in a straight forward way, rather than a series of complicated (and usually very fragile) text processing steps.
This leaves the topological sorting of the tasks to the programmer? This is neat, but that's one very useful feature of make that's missing.
How does this compare to e.g. @apenwarr's minimal `do`?
A true build system really needs to build out a DAG of dependencies to be efficient and fast. Compose this with https://github.com/ejholmes/walk and you're good.
I'm also using (for now) something based on these time checks (also pure posix + local, but local is extremely portable (tests well on 7 shells), though mine's a little more involved (automatic build job timing, controlled concurrency, robust failure/cancellation with autodeletion, fancy logging, filterable implicit dependencies, dependency + counting). It scales well to about 1000 source files. Then the lag starts to feel noticable.
One of the benefits I see for this approach is the possibility to handle spaces in filenames (AFAIK very difficult with gnumake). Sadly the provided function does not accept spaces in filenames.
Somehow I find it slightly amusing that I see ./a.out in 2017.
"notabug.org"... interesting.
Anyway, how does this compare, features-wise, with GNU Make? For example with make you have `./configure` files, do I also have them here?
has anyone tried tup? http://gittup.org/tup/
> The build script is easy to repurpose to your needs
No, it's not. This isn't under a free or open source license. The lack of license means that only an idiot would use it for anything.
Watch a movie Total Recall Full Online Translator
> This repo illustrates a way to manage a project using just plain Bourne sh, available on all Unix systems since 1977.
No, this code uses functions, which didn't exist in the original Bourne shell. They were introduced only in 1984.
Source: https://www.in-ulm.de/~mascheck/bourne/#variants