|
|
|
|
|
|
by rossy
3219 days ago
|
|
|
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.) |
|
|
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