Polyglot Makefiles
agdr.org
agdr.org
Author probably wants to use `private` for those target-local variables, though.
For example,
R: .SHELLFLAGS := -e
R: SHELL := Rscript
R:
greeting = "bonjour"
message(paste0(greeting, ", R!"))
R: private .SHELLFLAGS := -e
R: private SHELL := Rscript
R:
greeting = "bonjour"
message(paste0(greeting, ", R!"))
Usually I prefer to build up richer stages like this using the system shell anyway, though. Build a target which in turn is executed by the shell normally to traverse the next edge in the graph. But I can see how this mechanism has its uses.
See also https://www.gnu.org/software/make/manual/html_node/Target_00...
[just](https://github.com/casey/just) is a tool that feels similar to make but is designed explicitly for the purpose of running commands.
I think of this as a simple CLI for your project workflow. You still really want to avoid putting code into a Justfile and put it into scripts. But the Justfile helps provide a slightly nicer UX and automatically invoke dependencies.
The lack of a standard argument for getting help doesn't make it problematic for use as a command runner. You can't get atomatically all available commands from a Makefile just like you can't get all command-line flags from an executable. The program/Makefile has to provide it by itself.
Most people forget to mark their targets .PHONY, so they have a subtle bug in their build (touch build; touch test).
----
But shell also suffers from the problem where it doesn't list the commands. I filed a bug for Oil shell here:
https://github.com/oilshell/oil/issues/751
I mentioned a couple other "frameworks" there like just, go, Taskfile, etc.
But it should really just be built into the shell, since it's so common. And there should be command completion too, which I think bash-completion has for Makefiles on many distros.
Apparently there is no standard name for this kind of "task runner". But I think shell makes a lot more sense than a custom format, because there are many instances where you need a simple loop or conditional. It scales better. (And Oil also fixes bad shell syntax while remaining compatible: http://www.oilshell.org/blog/2020/01/simplest-explanation.ht...)
If anyone wants to help let me know :) The code is plain Python and pretty hackable. However it generates fast C++, so you get the best of both worlds (in progress)
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
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 often, so...
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.
> 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.
#!/usr/bin/make -f
$ process-data.mk INTSV=a.tsv DB=largefile.gz OUTDIR=finished
FWIW, using make -f in the shebang is also done for debian/rules in Debian package builds. I don't know if it serves any real purpose. I suppose it permits one to write a bespoke script for building targets without using make.[2] I guess I wouldn't be surprised if someone, somewhere depended on that capability, given how old and widespread Debian packages are.
[1] /usr/bin/env make -f would be better, but then you run afoul of the problem that you can't portably pass more than a single explicit shebang command argument.
[2] Which I see now is a bonus to your process-data.mk script. It could be replaced with a non-make version without effecting callers.
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...
#!/bin/sh
# make ignores next line \
set -e
# make ignores next line \
exec make -f "$0" "$@"
Personally, I try to use POSIX Makefiles, but I often find that they're most useful as a target for Makefile generators (in my case, these are usually a shell script called configure).
The most common mistake of that sort that I've seen is people trying to do complex conditionals inside their makefiles when they clearly would be better off in a Shell script. (I'm looking at you, fans of ifeq.)
Once POSIX standardizes "!=" then POSIX-portable conditionals will be possible using the same technique as above, replacing, e.g. OS = $(shell $(OS.exec))$(OS.exec:sh) with just OS != $(OS.exec). Though, you'd need to wait for Solaris, AIX, and macOS gmake[1] to add support for !=.
Alternatively, if you add an extra level of indirection using .DEFAULT to capture and forward make invocations, you can simply pass OS, etc, as invocation arguments. Indirection solves everything, though, so that's cheating.
[1] Apple's ancient GNU Make 3.81 predates != support. :(
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.
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.
Alas, I think the developers have in fact done just that. Make is not a build system. Make is a batch shell.
Build2 didn't produce a better make, they produced yet another C++ build system.
https://build2.org/build2/doc/build2-build-system-manual.xht...
If you have to write plugins to describe the rules that walk the edges of the DAG, then you haven't captured the essence of Make. It isn't just the DAG, its also the ability to walk graph edges with a generic shell alone. Here's some examples of things that we're using it for:
- Compile C, C++, and FORTAN on a common DAG for 5 unique ABIs.
- Parallelizing and sequencing atmospheric analysis with orbital mechanics programs.
- Post-processing our regression test suite.
- Executing and verifying SystemVerilog tests.
- Generating documentation with Doxygen and LaTeX.
- Generating linear flash images and a compressed initial filesystem.
- Transforming said initial filesystem into a linkable object.
Make does all of things without any prior knowledge of any of them, because it just uses the shell to express how the edges are walked. In some cases, we build the program that traverses an edge and express that as just another dependency in the chain.
If you have to write and compile plugins into build2 to do things like that, then you haven't re-implemented Make. You've just created another purpose-dedicated build tool. That's fine if its what you set out to do. But that also means statements like "We believe, paraphrasing a famous quote, that those who do not understand make are condemned to reinvent it, poorly." do not belong in your documentation. Because I don't think you understand Make.
Pull requests are welcome.
Edit: I'm the author.