How does this compare to e.g. @apenwarr's minimal `do`?
Show HN: Minimal build system using just /bin/sh
21–30 of 65 posts
Re: Show HN: Minimal build system using just /bin/sh
#22> 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
It also uses the "local" keyword, which is non-portable.
People like to bash the autotools, but they exist for exactly this reason - they already spent decades working through all these gritty details to ensure the scripts generated are portable. To paraphrase Spencer "Those who do not understand autotools are doomed to re-invent them, poorly."
Re: Show HN: Minimal build system using just /bin/sh
#23This 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.
Yes, that's true. I'm still noodling on that, primarily to enable parallel builds. Outside of parallel builds, however, I actually prefer an explicit sequence of steps to so-called "declarative syntax". The frequency with which I find bugs in the dependency graph of `Makefile`s [1][2][3] suggests that people are starting from a sequence of commands anyway. And it's better for the reader as well to see the commands la…
> The frequency with which I find bugs in the dependency graph of `Makefile`s [1][2][3] suggests that people are starting from a sequence of commands anyway
This is why the more elaborate build systems recognize dependencies automatically. For Makefiles, usually some sub-Makefile is generated automatically and then included. For language-specific build systems like OPAM (OCaml) or Cargo (Rust), this is one of their core features: As a programmer, don't care about maintaining dependency definitions! Whenever a source file is changed, the build system recalculates the relevant part of the dependency graph as well.
Re: Show HN: Minimal build system using just /bin/sh
#24Earlier quoted context omitted.
I'm having a hard time thinking of a use case for complex data structures in a build script. Can you give a real world example? Array is the only one that I have found lacking, in my experience.
If you aim for slightly larger projects and efficiency, you'd need at least a DAG (because that's the fundamental nature of a dependency graph). You can find a nice explanation in the "tup" build tool, although there are of course many others: http://gittup.org/tup/ And yes, you can express DAGs with text and/or filesystem operations (plus symlinks), but not efficiently and writing code that operates on that level is…
Tup is pretty darn amazing. I've never had such a high success rate while writing build rules under it. "Once it builds, it has no bug". Not to mention the great speed to begin with.
Is there any similar build system? I know of https://github.com/droundy/fac, but it's not cross-platform
Re: Show HN: Minimal build system using just /bin/sh
#25> 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
It also uses the "local" keyword, which is non-portable. People like to bash the autotools, but they exist for exactly this reason - they already spent decades working through all these gritty details to ensure the scripts generated are portable. To paraphrase Spencer "Those who do not understand autotools are doomed to re-invent them, poorly."
Uh-uh. Pray tell me an actual extant platform without `local`.
Debian dash deems 3 POSIX extensions basic enough to be in /bin/sh -- including `local`. https://www.debian.org/doc/debian-policy/ch-files.html#s-scr...
I don't care about some spherical-cow ideal of portability. It has its own costs -- like autotools. This is why OP makes no mention of POSIX or portability.
(This exchange regurgitates https://www.reddit.com/r/tinycode/comments/6md2l8/make_gmake..., albeit with more mutual sneering.)
Re: Show HN: Minimal build system using just /bin/sh
#26> 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
It also uses the "local" keyword, which is non-portable. People like to bash the autotools, but they exist for exactly this reason - they already spent decades working through all these gritty details to ensure the scripts generated are portable. To paraphrase Spencer "Those who do not understand autotools are doomed to re-invent them, poorly."
That's the argument for autotools, but I wholeheartedly disagree. Untested code can be assumed not to work, so if a build script doesn't work on a certain platform, what's the likelihood that the C program it's building will work on that platform? When you see a poorly-written autoconf script checking for basic things like size_t, you have to wonder if the program it's building really supports pre-ANSI C. This wastes real time on not-so-uncommon platforms like Cygwin and MSYS2, where spawning subshells is slow and running ./configure can take minutes.
So if you've never tested your program on a platform where /bin/sh doesn't understand local, feel free to use local in the build script. Bashisms like local are safer anyway. Variable scoping is good. (Though I guess the author's claim of it working in a 70s era Bourne shell is still wrong.)
Re: Show HN: Minimal build system using just /bin/sh
#27One 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.
Re: Show HN: Minimal build system using just /bin/sh
#28Earlier quoted context omitted.
I'm having a hard time thinking of a use case for complex data structures in a build script. Can you give a real world example? Array is the only one that I have found lacking, in my experience.
If you aim for slightly larger projects and efficiency, you'd need at least a DAG (because that's the fundamental nature of a dependency graph). You can find a nice explanation in the "tup" build tool, although there are of course many others: http://gittup.org/tup/ And yes, you can express DAGs with text and/or filesystem operations (plus symlinks), but not efficiently and writing code that operates on that level is…
Regarding DAG: tsort (1) sorts input lines by interpreting them as a list of edges. I guess that's what you where referring to when you said "cumbersome" :)
$ cat > f
a c
a d
b c
^D
$ tsort f
a
b
d
cRe: Show HN: Minimal build system using just /bin/sh
#29I 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 h…
I'm having a hard time thinking of a use case for complex data structures in a build script. Can you give a real world example? Array is the only one that I have found lacking, in my experience.
> I'm having a hard time thinking of a use case for complex data structures in a build script. Can you give a real world example?
Look at how a modern build system (like qbs) organizes the build. It builds a declarative object graph describing the project and maps that to a dependency graph where each node can be a relatively complex object ("compile C++ file X using flags Y" or "link LargeSetOfFiles") annotated with modification data (like input file hashes). (Then it compares the dependency graph to what is found on the system and creates a list of commands to execute in order to bring whatever is on the system to the desired state, i.e. create an up to date build).
Re: Show HN: Minimal build system using just /bin/sh
#30Earlier quoted context omitted.
If you aim for slightly larger projects and efficiency, you'd need at least a DAG (because that's the fundamental nature of a dependency graph). You can find a nice explanation in the "tup" build tool, although there are of course many others: http://gittup.org/tup/ And yes, you can express DAGs with text and/or filesystem operations (plus symlinks), but not efficiently and writing code that operates on that level is…
Tup is pretty darn amazing. I've never had such a high success rate while writing build rules under it. "Once it builds, it has no bug". Not to mention the great speed to begin with. Is there any similar build system? I know of https://github.com/droundy/fac , but it's not cross-platform
tup sounds similar to qbs. I found qbs to be a most amazing C++ build system, it's the only one I used that is
1) reasonably easy to use 2) very fast 3) very correct
Most build systems fail 3), usually 2) and often also 1).