Closed copumpkin closed 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.
I see, thanks!
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 throughgo 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.