3 ms·

# Go parameters GOCMD=go GOBUILD=$(GOCMD) build GOCLEAN=$(GOCMD) clean GOTEST=$(GOCMD) test GOGET=$(GOCMD) get BINARY_NAME=mybinary

# Go parameters GOCMD=go GOBUILD=$(GOCMD) build GOCLEAN=$(GOCMD) clean GOTEST=$(GOCMD) test GOGET=$(GOCMD) get BINARY_NAME=mybinary BINARY_UNIX=$(BINARY_NAME)_unix A little bit of Clean Code education is needed here :) Why on earth do you want to introduce so unnecessary abstraction? If those would use a lot of switches which you don't want to duplicate and just possibly want it to change in one place, I would say OK. But you don't even use it that way: $(GOBUILD) -o $(BINARY_NAME) -v ./... CGO_ENABLED=0 GOOS=linux GOARCH=amd64 $(GOBUILD) -o $(BINARY_UNIX) -v So this doesn't make sense at all. You should write the commands as it is and it would be a lot easier to read an already hard-to-read syntax Makefiles anyway.

andreineculau 9y ago
Having a GOCMD may be useful, but not like this. In bigger systems, you may alter the PATH in the CI env or part of the Makefile itself, or PATH differs from machine to machine, OS to OS, etc, or you want to say that GOCMD is either "gofork" or "go". Regardless of the situation you'd want to use an absolute path to the executable so that if you run make in verbose mode you'd see "/usr/bin/go" or "/home/user/local/bin/go" or "/this/is/not/the/real/go" printed. Being super strict about this pattern will keep you sane.
striking 9y ago
I'd say "GOCMD" would be sane if it were phrased "GO" instead. That's the convention for most commands in makefiles, stemming from the fact that if you need to invoke `make` recursively, you use `$(MAKE)` (provided automatically) to do it so you don't break nice things like -j.