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.
Show HN: Minimal build system using just /bin/sh
31–40 of 65 posts
Re: Show HN: Minimal build system using just /bin/sh
#32A 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.
Thus ninja https://ninja-build.org/
Re: Show HN: Minimal build system using just /bin/sh
#33I 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'.
Re: Show HN: Minimal build system using just /bin/sh
#34I 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…
Also most current Unixes have at least Bash. Bourne shell is surprisingly rare outside BSD.
Re: Show HN: Minimal build system using just /bin/sh
#35Earlier quoted context omitted.
Looking as the sh code, it appears that it will work without tab characters. https://stackoverflow.com/a/2131227/1144060 So there's that.
As it happens, I was moved to create this standalone repo showing off my current build setup after writing this comment: https://www.reddit.com/r/vim/comments/6l8z34/vim_betrayed_me... So yes, eliminating tabs (or rather the execrable requirement of using tabs) was absolutely a prime goal.
It's not a requirement - I give you: .RECIPEPREFIX
> If you prefer to prefix your recipes with a character other than tab, you can set the .RECIPEPREFIX variable to an alternate character
That said, how hard is it really to disable tab expansion in your editor? I have a block of configuration dedicated to the different indentation requirements of different programming and configuration languages. In more modern editors, I don't even have to do anything at all to edit Makefiles with tabs - they come pre-configured to do the right thing.
Re: Show HN: Minimal build system using just /bin/sh
#36"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?
The whole goal of this approach is to get out of the vicious cycle of build files generating other build files, so no `configure`. `configure` is not in itself a feature. What purpose does it fulfill for you? Then we can discuss how we may serve that purpose in some more lightweight manner.
I have the feeling your way of thinking is 'remove every abstraction so that we end up with a simpler system'. This works in some cases, but certainly not all of them. configure is one of them.
Why? Try removing a configure script for even a simple autotools project, and ensure that it still builds fine on all previously supported platforms by writing a cross platform Makefile. Good luck with that.
Re: Show HN: Minimal build system using just /bin/sh
#37Earlier quoted context omitted.
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.…
Any OS which use the Korn shell as /bin/sh, for example Solaris 10, 11, and illumos:
$ /bin/sh -c "fail() { local f; }; fail"
/bin/sh[1]: local: not found [No such file or directory]
$ /bin/sh --version
version sh (AT&T Research) 93t+ 2010-03-05
$ uname -rsv
SunOS 5.11 joyent_20160721T174127Z
Whether you regard these platforms as extant depends on your point of view. Most people wouldn't, and that's fine. We'd naturally disagree ;)
Re: Show HN: Minimal build system using just /bin/sh
#38Earlier 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…
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 c
The problem is not tsort, it is adding, removing, updating items in such a text file. (not to mention nasty corner cases like filenames containing whitespaces, or the security implications of filenames containing newlines)
Re: Show HN: Minimal build system using just /bin/sh
#39Somehow I find it slightly amusing that I see ./a.out in 2017.
Re: Show HN: Minimal build system using just /bin/sh
#40I 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…
Maybe they're not using a language with insanely bloated compile times?