machine-drivers / docker-machine-driver-xhyve

docker-machine/minikube/minishift driver plugin for xhyve/hyperkit (native macOS hypervisor.framework)
https://godoc.org/github.com/machine-drivers/docker-machine-driver-xhyve
BSD 3-Clause "New" or "Revised" License
888 stars 74 forks source link

[Question] Why use `go generate` for libhyperkit? #165

Closed copumpkin closed 7 years ago

copumpkin commented 7 years ago

I'm packaging docker-machine-driver-xhyve and am working through its build process to fit it into my packaging workflow. One thing that puzzled me was your decision to invoke the native (OCaml and otherwise) builds through go generate, in https://github.com/zchee/docker-machine-driver-xhyve/blob/master/vendor/github.com/zchee/libhyperkit/xhyve.go and https://github.com/zchee/docker-machine-driver-xhyve/blob/master/vendor/github.com/zchee/libhyperkit/xhyve_qcow2.go.

What's the advantage of going through go generate rather than just invoking the commands directly in your top-level makefile? I found it a bit confusing but I'm probably missing something.

zchee commented 7 years ago

@copumpkin It almost for easy maintenance. Now separated hyperkit bindings on libhyperkit, so if needs change to any build way of OCaml bindings(file structure etc), need to change the libhyperkit side, also docker-machine-driver-xhyve Makefile.

I know go generate is not safer(can rm etc), and almost for the developers. But we provide the pre-build binary, and if some users want to go build or make for build binary, I decided to think that user was a "developer". I do not know which way is better, but now I am using go generate for the reasons above.

If your question is resolved, please close it.

copumpkin commented 7 years ago

I see, thanks!