Destination should generate folder that does not exist.

[jgimeno]

I think the destionation option should generate the folder if it does not exist instead of throwing an error. Or at least have a flag to be able to do this. In my opinion!

[vaidya-yd]

I'm also experiencing this - Eg. If mocks folder is not present and the below command is issued, the below happens. mockgen -destination mocks/dal.go persistence Dal 2019/01/02 14:20:51 Failed opening destination file: open mocks/dal.go: no such file or directory I'm running Mac OS Mojave and using GoLang go1.11 darwin/amd64 This seems to be the only difference between machines where I've seen this error vs where I haven't (works perfectly fine on High Sierra in the limited machines I've seen) - there is no difference in the permissions etc In fact the below command works perfectly fine - just that I need to add this line before the generation. go:generate mkdir -p mocks

[poy]

@jgimeno It is supposed to work that way, for example:

$ cd $GOPATH/src/github.com/golang/mock/sample/
$ rm -rf mock_user/
$ go generate
$ ls mock_user
  mock_user.go

Can I see a go env. Also to @vaidya-yd 's point, are you using Mojave ?

[vaidya-yd]

Hi @poy, Yes, I'm using Mojave. My other colleagues who are not using Mojave are not experiencing this issue on the same codebase. This is my go env.

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/vaidyanathan.s/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/vaidyanathan.s/code/go/src/github.fkinternal.com/altair:/Users/vaidyanathan.s/code/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/8_/fjxbznns6gx7v_94hr7n_r0x19t7ng/T/go-build854347914=/tmp/go-build -gno-record-gcc-switches -fno-common"

[poy]

What is your version of go (e.g., go version)?

I was able to get this feature to work correctly on Mojave, but I wonder if it has anything to do with the new "Full Disk Access" feature that was introduced in Mojave.

[vaidya-yd]

go version go1.11 darwin/amd64 When I was debugging, there was a point when I could not write any file to /tmp in any language programatically (permission denied) ! I had to reboot the OS and its updates to take place before that problem got resolved - but this current problem wouldn't resolve. I then tried giving the go and the mockgen executables the "Full Disk Access" but that has not helped either.

[poy]

Very interesting. I'm curious if other applications would have this problem. If you ran a simple application (via go build), would that work?

package main

import (
    "flag"
    "log"
    "os"
    "path/filepath"
)

func main() {
    destination := flag.String("destination", "/tmp/something", "where to create the directory")
    flag.Parse()

    if err := os.MkdirAll(filepath.Dir(*destination), os.ModePerm); err != nil {
        log.Fatalf("Unable to create directory: %s", err)
    }

    log.Print("success")
}

[vaidya-yd]

The above application works fine now. However this wouldn't have worked a while back if I hadn't rebooted my system. Any other leads on how to resolve the issue at hand ?

[jgimeno]

Sorry to be late to the party, this is my go env:

GOARCH="amd64"
GOBIN=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/lr/20v7hz1j5cnfrzxlyw47bw5r0000gn/T/go-build897521724=/tmp/go-build -gno-record-gcc-switches -fno-common"

And my go version : go1.11.4 darwin/amd64

[codyoss]

Hey @vaidya-yd & @jgimeno did you ever find a solution to this? It sounds to me like a local env issue.

[codyoss]

I am going to close this due to inactivity. If it pops up again lets open a new issue and investigate with fresh data.