You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The libvirt-go cgo bindings will likely provide the best stability and error handling capabilities for interacting with libvirt, so we should add the ability to use them. They must be guarded by a build tag.
If built without the tag, all cgo operations will return error stubs.
The text was updated successfully, but these errors were encountered:
mdlayher
changed the title
Add qmp.Monitor which uses cgo bindings to interact with libvirt
qmp: add Monitor which uses cgo bindings to interact with libvirt
May 3, 2016
I've been looking into this issue and here is one idea on addressing the build tag guard.
I thought about creating 3 files like so: libvirtgo.go (this file contains implementation methods entry point for Monitor, etc...
It will call the correct implementation method based on the GOOS where it's built)
libvirtgo_linux.go (this file contains the calls to libvirt-go package)
libvirtgo_others.go [build tag: // +build !linux](this file contains operations returning error stubs)
Of course, there will be *_test.go files with the corresponding tests.
Since we are providing packages and not an application, we don't explicit vendor our dependencies. Importing it without vendoring is fine, especially because both repositories belong to DigitalOcean.
The libvirt-go cgo bindings will likely provide the best stability and error handling capabilities for interacting with libvirt, so we should add the ability to use them. They must be guarded by a build tag.
If built without the tag, all cgo operations will return error stubs.
The text was updated successfully, but these errors were encountered: