> 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.
No, this code uses functions, which didn't exist in the original Bourne shell. They were introduced only in 1984.
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."
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.)
$ /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 ;)
$/bin/sh -c "fail() { local f; }; fail"
$
$alias local
local=typeset
$
Who's that?
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.)
That's true, but in my case it turned out to be insignificant. While changing all the autoconf junk in > 100 plugins could move the total build time from 50 minutes down to 40, I'd need an order of magnitude decrease in build time to warrant the work. I say order of magnitude because its only at a 5 minute build time that the entire dev process would see a paradigm shift-- at that point I could, with a straight face, stop shipping Linux binaries and just suggest that users compile the software themselves. (Of course that's not great usability for a whole class of Ubuntu users, but at build time == 5 minutes some other dev could easily come along and package things up with ease.)
Also, the extra wasted time under Windows isn't the fault of autoconf. Try doing `git any_subcommand` in msys2 and you'll get latency so high you'd think it were a practical joke.
Edit: added parenthetical
if it doesn't just magically work, you're largely sol.
sometimes you can put in a basic build in its place, or find some environment variables to fiddle with. but usually..
He may have used functions to keep this to a single file and I doubt his 1977 comment (now changed to "30 years") was to be taken literally.
Anyone aware of the overzealous use of more complex build systems in situations where they are not necessary would understand his point. It is possible to build portable software without autoconf and makefiles.
Example: http://nacl.cr.yp.to