[jperkin]

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."

[rossy]

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.)

[jancsika]

> This wastes real time on not-so-uncommon platforms like Cygwin and MSYS2, where spawning subshells is slow and running ./configure can take minutes.

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

[convolvatron]

you're missing another huge problem with autoconf and friends.

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..

[akkartik]

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.)

[jperkin]

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

It wouldn't work on Solaris 9 and older either as the original /bin/sh also doesn't support "local", but as those releases are EOL it's fine to discount them.

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 ;)

[akkartik]

That's good to know, actually. Thanks! Sorry about my tone before. Are there any other platforms that actually benefit from autotools, that you're aware of?

[JdeBP]

OpenBSD uses the Korn shell for /bin/sh and this is not true there.

    $/bin/sh -c "fail() { local f; }; fail"
    $

OpenBSD's /bin/sh defines several aliases as standard.

    $alias local
    local=typeset
    $

M. Agaram has stated elsewhere that xe was using OpenBSD sh as a poor man's POSIX conformance test.

[jwilk]

> M. Agaram

Who's that?

[akkartik]

That's my last name. Perhaps the M stands for "Monsieur" :)