3 ms·
Ehh. If I'm writing a Makefile, team context or no, it's almost certainly because I don't expect other people to be more familiar with Make than I am. If anythi
by eropple 4y ago
Ehh. If I'm writing a Makefile, team context or no, it's almost certainly because I don't expect other people to be more familiar with Make than I am. If anything, I would expect ONESHELL to map to how most programmers think Make already works, even though it doesn't. I know I have to go look up the various Make-isms whenever I need to do anything complex.
And a Make supergenius, should I ever meet one, surely will look at the top of the file or derive from "incorrect" code that something is nonstandard.
I'd love better tools that take the good parts of Make (around file transformations, mostly) and expose them more effectively in shells (because doing so in a more fully featured programming language often results in different and worse hacks--hi, Rake) but using Make to do things more people will find predictable seems fine to me.
- eqvinox 4y agoI guess I should've been more clear. My point is other people /using/ your Makefile, not editing it. You know what you're running. You don't know what everyone else is running. I've singled out ONESHELL because it will be silently ignored by non-GNU make, and it will behave ever so slightly different enough to cause extremely hard to find bugs. Example: .ONESHELL: sometarget: someinput ␉BASEDIR=other_expression ␉SHELLVAR=complicated_expression ␉rm -rf $$BASEDIR/$$SHELLVAR (obviously extreme to illustrate the point, but you get the idea.)
- eqvinox 4y agobtw. On the BSDs, GNU make is "gmake" while plain "make" is POSIX-compliant BSD make. Better hope you never make the easy mistake of forgetting that "g"… (If you use any of these features — please rename your Makefile to GNUmakefile. Please. I beg you.)