Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Minimal build system using just /bin/sh

notabug.org

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Show HN: Minimal build system using just /bin/sh

#51

Post by edwinyzh »

vog wrote: post #11

I 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…

Speaking of using Python or Node.js as a language for a build process, there were so many times it failed when I trying to run the build script included in the github open source project I found interesting and downloaded to my local file system, and usually it's a project not written in my familiar language, and since I'm NOT familiar with Python nor node.js, so when the build script emit something like a dependency error, after several tries without success, I usually just give up.

Re: Show HN: Minimal build system using just /bin/sh

#52

Post by CJefferson »

dom0 wrote: post #30
chenglou wrote: post #24

Earlier quoted context omitted.

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

What makes tup amazing is it traces which files a program touches, so assuming your programs obey the rule "I need to rerun if I have different command line arguments or something I read has changed", you get perfect dependencies for any program. I use it for running experiments with custom programs and scripts all the time, and it just refund the parts I need.

Re: Show HN: Minimal build system using just /bin/sh

#53

Post by user5994461 »

majewsky wrote: post #45
vog wrote: post #11

I 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 see you've not yet encountered Alpine-based Docker containers. $ docker run --rm -ti alpine sh / # bash sh: bash: not found / # python sh: python: not found / # perl sh: perl: not found / # ruby sh: ruby: not found Sure, you can install all of these with a single `apk add`, but it makes your container much fatter, i.e. every CI job that has to pull the image will be taking a longer time. Same for when you push the…

It's one of the reason that alpine should not be used outside of tests and toys projects. It cannot be substituted to an usual distribution.

Re: Show HN: Minimal build system using just /bin/sh

#54

Post by akkartik »

jperkin wrote: post #37
akkartik wrote: post #25

Earlier quoted context omitted.

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

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?

Re: Show HN: Minimal build system using just /bin/sh

#55

Post by wrs »

majewsky wrote: post #45
vog wrote: post #11

I 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 see you've not yet encountered Alpine-based Docker containers. $ docker run --rm -ti alpine sh / # bash sh: bash: not found / # python sh: python: not found / # perl sh: perl: not found / # ruby sh: ruby: not found Sure, you can install all of these with a single `apk add`, but it makes your container much fatter, i.e. every CI job that has to pull the image will be taking a longer time. Same for when you push the…

In a base Alpine container, it would be awfully hard to build anything interesting. You are probably going to need to install some build tools first anyway. (Thus the two-stage container pattern.)

Re: Show HN: Minimal build system using just /bin/sh

#56

Post by jancsika »

rossy wrote: post #26
jperkin wrote: post #22

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

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…

> 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

Re: Show HN: Minimal build system using just /bin/sh

#58

Post by convolvatron »

rossy wrote: post #26
jperkin wrote: post #22

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

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…

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

Re: Show HN: Minimal build system using just /bin/sh

#59

Post by JdeBP »

jperkin wrote: post #37
akkartik wrote: post #25

Earlier quoted context omitted.

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

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.

Re: Show HN: Minimal build system using just /bin/sh

#60

Post by feelin_googley »

jwilk wrote: post #19

> 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

I just rewrote it without functions in about 5 min. It probably takes less than a minute for a faster typist.

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

Post reply on HN