4 ms·

This is only cleaner in your simple case. Make's power lies in dependency tracking and its declarative approach to defining those dependencies. When you use ma

by jlg23 11y ago

This is only cleaner in your simple case. Make's power lies in dependency tracking and its declarative approach to defining those dependencies. When you use make anyway, adding those targets there is the logical thing to do. One interface instead of two. It's even less lines of code than your proposed solution (which btw does not fail hard like make does, so a recipe for desaster). Finally: Pretty please, sh, not bash. Almost none of the bash-scripts out there use actual bash-features and those that do can usually easily be rewritten to just rely on a plain posix shell.

kps 11y ago
For makefiles, even GNU make executes commands using /bin/sh (unless you set $(SHELL) explicitly); trouble is, many Linux systems use bash for /bin/sh, and its sh emulation is lacking.
chubot 11y ago
My point is precisely that the script is not using "Make's power in dependency tracking". It's just running commands. If you need Make, use Make; otherwise use shell. It's far from unusual to have a Makefile and some shell scripts at the top level of a project. Make's semantics are to invoke the shell at EVERY LINE. This is slow and makes quoting a nightmare (try quoting find or sed in bash in Make correctly; you cannot directly invoke them from Make). Conversely, bash's semantics do not involve make whatsoever :) Shell also has local variables for modularity, and better constructs for conditionals and iterations. And functions. Make has a poor man's implementation of Turing-complete constructs compared to shell (which is a little ironic since shell is already sort of a poor man's procedural language). 'set -o errexit' makes bash fail on errors. Also, as mentioned, the Makefile isn't using phony targets. Neither shell or Make is perfect, but shell is the more appropriate tool when you're not making use of Make's incremental build features. Another pattern I find useful is to have the actions take more arguments, like: ./run.sh dev-frontend --flag-for-testing which is implemented just like this: dev-front-end() { ./frontend.py --port 8080 --other-default-flag "$@" } "$@" The arguments to Make are actually TARGETS/files and not functions, so I don't think you can do this.
- jlg23 11y ago
  > Make's semantics are to invoke the shell at EVERY LINE. This is slow [...] I assume you mean commands here? Actually, how slow is it? Ever measured it? I am sure me writing this line took more time than they could save by a rewrite over the course of a few years of using the performance optimized version. > Shell also has local variables for modularity, and better constructs for conditionals and iterations And variables in make that you set for a command are only visible to it. Besides - wasn't your point that the OP should not use make because s/he does not use its features? > 'set -o errexit' makes bash fail on errors Indeed it does, it was just missing from your better version. > Another pattern I find useful is to have the actions take more arguments [...] The arguments to Make are actually TARGETS/files and not functions, so I don't think you can do this. Yes, one communicates with make through variables, not through arguments. Over the last 20 or so years I've done my fair share of shell scripting and of writing makefiles. Maybe I am just too old and boring to get excited over this, but let me recap: The OP happens to be using make, s/he used an elegant hack to have the file document itself and its usage. S/He wrote about the latter. No, I am not impressed by the post - I used a similar technique in 2003 or 2004 to bootstrap the documentation of a very complex build system - and I'm sure others have before and after me. But I like the concise article. Debating whether make is "better" than "sh" is completely off-topic here - if there was a universal truth we'd not have seen tools like psh, scsh and the rest of language-specific shell substitutes nor would we have the myriad of language-specific build tools. Back then, when I was young and naive, I've implemented a few of those myself. But now I am not young anymore. And now I naively believe that people should use what they are most productive with. Or everybody come to their senses and just use lisp.

by jlg23 11y ago

kps 11y ago

For makefiles, even GNU make executes commands using /bin/sh (unless you set $(SHELL) explicitly); trouble is, many Linux systems use bash for /bin/sh, and its sh emulation is lacking.

chubot 11y ago

My point is precisely that the script is not using "Make's power in dependency tracking". It's just running commands. If you need Make, use Make; otherwise use shell. It's far from unusual to have a Makefile and some shell scripts at the top level of a project. Make's semantics are to invoke the shell at EVERY LINE. This is slow and makes quoting a nightmare (try quoting find or sed in bash in Make correctly; you cannot directly invoke them from Make). Conversely, bash's semantics do not involve make whatsoever :) Shell also has local variables for modularity, and better constructs for conditionals and iterations. And functions. Make has a poor man's implementation of Turing-complete constructs compared to shell (which is a little ironic since shell is already sort of a poor man's procedural language). 'set -o errexit' makes bash fail on errors. Also, as mentioned, the Makefile isn't using phony targets. Neither shell or Make is perfect, but shell is the more appropriate tool when you're not making use of Make's incremental build features. Another pattern I find useful is to have the actions take more arguments, like: ./run.sh dev-frontend --flag-for-testing which is implemented just like this: dev-front-end() { ./frontend.py --port 8080 --other-default-flag "$@" } "$@" The arguments to Make are actually TARGETS/files and not functions, so I don't think you can do this.

jlg23 11y ago
> Make's semantics are to invoke the shell at EVERY LINE. This is slow [...] I assume you mean commands here? Actually, how slow is it? Ever measured it? I am sure me writing this line took more time than they could save by a rewrite over the course of a few years of using the performance optimized version. > Shell also has local variables for modularity, and better constructs for conditionals and iterations And variables in make that you set for a command are only visible to it. Besides - wasn't your point that the OP should not use make because s/he does not use its features? > 'set -o errexit' makes bash fail on errors Indeed it does, it was just missing from your better version. > Another pattern I find useful is to have the actions take more arguments [...] The arguments to Make are actually TARGETS/files and not functions, so I don't think you can do this. Yes, one communicates with make through variables, not through arguments. Over the last 20 or so years I've done my fair share of shell scripting and of writing makefiles. Maybe I am just too old and boring to get excited over this, but let me recap: The OP happens to be using make, s/he used an elegant hack to have the file document itself and its usage. S/He wrote about the latter. No, I am not impressed by the post - I used a similar technique in 2003 or 2004 to bootstrap the documentation of a very complex build system - and I'm sure others have before and after me. But I like the concise article. Debating whether make is "better" than "sh" is completely off-topic here - if there was a universal truth we'd not have seen tools like psh, scsh and the rest of language-specific shell substitutes nor would we have the myriad of language-specific build tools. Back then, when I was young and naive, I've implemented a few of those myself. But now I am not young anymore. And now I naively believe that people should use what they are most productive with. Or everybody come to their senses and just use lisp.