31–40 of 44 posts
I wish someone would write a modern alternative to GNU Make. I've looked and there don't seem to be any. The closest is Ninja but it doesn't seem to be intended to be hand written.
Sometimes it's just simpler to bite the ancient bullet and go with a Makefile, with all its included pains and gotchas rather than try to figure out how to get the fancy new makefile replacement installed in all the relevant environments.
For complicated pipelines that I want to reuse multiple times, I have turned Makefiles into executables by putting this at the top: #!/usr/bin/make -f And then putting them in my $PATH. I run them with arguments like: $ process-data.mk INTSV=a.tsv DB=largefile.gz OUTDIR=finished This makes me feel like I've sold my soul to the devil, and that I'm just living on borrowed time until it all fails and falls apart. It has…
I can see two areas in which it might break. I might put #!/usr/bin/env make -f in case it's somewhere in else in PATH. Also some systems (BSD, old commercial Unix) have non-gnu-compatible make and sometimes call their gnu make port "gmake" or "gnumake".
There's also a special bonus papercut you might hit when /usr/bin/env is in the shebang with extra arguments: an infinite loop!
Sorry for the plug: I wrote about it here. https://www.crystae.net/posts/2019/11/08/two-shebang-papercu...
Earlier quoted context omitted.
I can see two areas in which it might break. I might put #!/usr/bin/env make -f in case it's somewhere in else in PATH. Also some systems (BSD, old commercial Unix) have non-gnu-compatible make and sometimes call their gnu make port "gmake" or "gnumake".
That shebang is appealing but unfortunately more than one argument (past the initial command name) in a shebang is unportable: some OSes will coalesce the extra arguments into one, others make them separate arguments. There's also a special bonus papercut you might hit when /usr/bin/env is in the shebang with extra arguments: an infinite loop! Sorry for the plug: I wrote about it here. https://www.crystae.net/posts/2…
I wish someone would write a modern alternative to GNU Make. I've looked and there don't seem to be any. The closest is Ninja but it doesn't seem to be intended to be hand written.
However, SnakeMake, Nextflow, etc feels excessively verbose compared to standard make. And the prior workflow managers of last decades were far worse. With standard make, you type pretty much exactly what you would for shell commands, and not too much more.
All other alternatives are going to be more verbose than make, and to me that's a negative.
I wish someone would write a modern alternative to GNU Make. I've looked and there don't seem to be any. The closest is Ninja but it doesn't seem to be intended to be hand written.
Earlier quoted context omitted.
The tool you want is remake: http://bashdb.sourceforge.net/remake/ This is GNU Make + a few patches. So it's 100% compatible. And you get an interactive debugger, and lots more stuff. For instance, to list out the commands: remake --targets No idea why this hasn't been merged upstream. Your larger point really stands, though: if you're just running commands, you shouldn't be using Make. But it is abused in that way o…
> remake --targets; No idea why this hasn't been merged upstream I would think because it's useless. The targets in a Makefile are very often just internal and aren't always meant to be run by the user.
Anyway, one could always have a 'help' target that prints a short documentation. This also avoid listing internal targets.
For complicated pipelines that I want to reuse multiple times, I have turned Makefiles into executables by putting this at the top: #!/usr/bin/make -f And then putting them in my $PATH. I run them with arguments like: $ process-data.mk INTSV=a.tsv DB=largefile.gz OUTDIR=finished This makes me feel like I've sold my soul to the devil, and that I'm just living on borrowed time until it all fails and falls apart. It has…
I can see two areas in which it might break. I might put #!/usr/bin/env make -f in case it's somewhere in else in PATH. Also some systems (BSD, old commercial Unix) have non-gnu-compatible make and sometimes call their gnu make port "gmake" or "gnumake".
#!/bin/sh
# make ignores next line \
set -e
# make ignores next line \
exec make -f "$0" "$@"
Earlier quoted context omitted.
> remake --targets; No idea why this hasn't been merged upstream I would think because it's useless. The targets in a Makefile are very often just internal and aren't always meant to be run by the user.
Many shell autocompleters would read the makefile to complete target names though, suggesting it is not useless. Anyway, one could always have a 'help' target that prints a short documentation. This also avoid listing internal targets.
> one could always have a 'help' target that prints a short documentation
Sure, that's fine. But the point is that if you have an unknown Makefile you can't (or shouldn't) just execute it without knowing what it will do. Makefiles should be treated as individual programs just like any other executable and there's no guaranteed standard way to get help from it.