0

Setup: macOS, bash, inside tmux. I use make installed via homebrew. When running make with my Makefile, I get

protoc -I=foo/bar/proto --cpp_out=foo/bar/proto foo/bar/proto/foo.proto
make: *** No rule to make target 'foo/bar/proto/foo.pb.h', needed by 'proto'.  Stop.
make: *** Waiting for unfinished jobs....

When I instead run gmake, the program is successful:

protoc -I=foo/bar/proto --cpp_out=foo/bar/proto foo/bar/proto/foo.proto
protoc -I=foo/bar/proto --python_out=foo/bar/proto foo/bar/proto/foo.proto

But the binaries are exactly the same:

$> readlink -f `which make`
/usr/local/Cellar/make/4.2.1_1/bin/gmake
$> readlink -f `which gmake`
/usr/local/Cellar/make/4.2.1_1/bin/gmake

How is this possible?

It was suggested that this question is a duplicate, which doesn't seem to be the case. I am aware, that the system-make is not necessarily GNU make or not a current version. But as proven above, the two commands refer to the exact same binary.

oarfish
  • 4,116
  • 4
  • 37
  • 66
  • I'm surprised I didn't find it defined in its man, but it according to the above QA gmake is part of the tools that behave differently depending on how they have been invoked. Typical example is `bash` which can be invoked as `sh` to execute in a POSIX-compatible environment. – Aaron May 20 '19 at 09:25
  • @Aaron I don't understand why that question refers to the same problem, since both commands in my case are symlinks to the same binary. – oarfish May 20 '19 at 09:29
  • In the other question (and in my `bash`/`sh` sample) there's also a single executable that can be called by two different names. The point is that the executable is capable to identify which name is has been called with and behave differently. In your case your makefile must been relying on GNU make syntax's which would be disabled when you invoke GNU Make through `make` rather than `gmake` – Aaron May 20 '19 at 09:34
  • 1
    But GNU `make` does *not* disable GNU Make extensions when you invoke it simply as `make`. See also https://unix.stackexchange.com/questions/144424/restricting-gnu-make-to-posix-make-behaviour – tripleee May 20 '19 at 09:57
  • @Aaron If that's true (the q itself does not comment on whether it's actually the same binary), I assume there's no way to turn off that behaviour? Seems crazy to me that the behaviour of a program is not 100% specified by the binary itself and what config it reads, but by the name it's called. – oarfish May 20 '19 at 10:16
  • I think I jumped to conclusions, while I'm pretty sure the executables in the linked question are the same (they report the same implementation when called with `--version`) I guess the accepted answer only meant to mention using different implementations, rather than using different ways to call GNU make for different behaviours. I've retracted my close vote, and I suggest you use `type gmake` & `type make` to make sure there's no alias or function that explains the different behaviour (`which` only resolves elements of `$PATH` and would miss them) – Aaron May 20 '19 at 11:18
  • @Aaron You're actually right, the problem was that I had an `alias make='make -j4'` defined. If you could describe why exactly that would cause a problem, you could make that an answer. – oarfish May 21 '19 at 06:54
  • Looks like it's a problem with the makefile itself that makes it unable to be run in parallel then, you find quite a few examples with a "make parallel fail" websearch, but you won't be able to get a definite answer without posting your makefile – Aaron May 21 '19 at 08:37

0 Answers0