On 7/19/19 12:09 PM, George Dunlap
wrote:
On 7/19/19 11:03 AM, Nicolas Belouin wrote:
On 7/19/19 10:50 AM, George Dunlap wrote:
On Jul 19, 2019, at 9:47 AM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
On Jul 19, 2019, at 8:34 AM, Nicolas Belouin <nicolas.belouin@xxxxxxxxx> wrote:
On 7/18/19 11:54 PM, George Dunlap wrote:
The Go bindings for libxl miss functions from libxl_utils, let's start
with the simple libxl_domid_to_name and its counterpart
libxl_name_to_domid.
NB that C.GoString() will return "" if it's passed a NULL; see
https://github.com/golang/go/issues/32734#issuecomment-506835432
Signed-off-by: Nicolas Belouin <nicolas.belouin@xxxxxxxxx>
Signed-off-by: George Dunlap <george.dunlap@xxxxxxxxxx>
---
v3:
- Wire into build system
- Add reference to C.GoString() handling NULL to commit message
Nicolas, could you test to see if this actually works for you?
Tested it, it works.
I must confess I do not use that import path as the new modules mechanism
introduced in Go1.11 downloads and compile a versioned copy of every
dependency per project, and this behavior is incompatible with the build
system used here.
It’s possible that something fundamentally has changed, but I suspect that rather you don’t quite understand how the current build system is supposed to work. (In which case a write-up in the tree would probably be useful.)
Go has always insisted that there be no binary compatibility between versions; so it’s always been necessary to re-compile all your libraries when upgrading from (say) 1.8 to 1.9. Which means that any useable distribution must also include all the source files necessary to recompile when you bump the version number.
So the core mechanism of the “install” is actually to copy all the source files necessary into the right local directory such that the go compiler can find them; ATM this is /usr/share/gocode/golang.xenproject.org/xenlight
Nit: This of course should have a `src/` between `gocode/` and `golang.xenproject.org/`.
NB also that this naming scheme was designed so that at some point in the future, we could actually host the xenlight packages at the URL provided.
-George
This new mechanism of modules is described here:
https://golang.org/cmd/go/#hdr-Modules__module_versions__and_more
The module system is intended to supersede the GOPATH approach and
provide a way to get versioned dependencies, as such
it does not rely on GOPATH at all and doesn't use sources or compiled
packages present in GOPATH elements such as /usr/share/gocode
and systematically fetch (at the asked version) and compile a copy of
the dependency as it might be a different version from the one
in GOPATH.
As far as I tried, I have been unable to build my module even with the
library installed.
I have to use xenbits.xen.org/git-http/xen.git/tools/golang/xenlight (or
one of its mirror) in order to build the module using the new
mechanism (the golang.xenproject.org/xenlight works when building with
modules mode disabled).
I took a look at the module stuff when it came out, and I was never able
to make sense of how it was supposed to work.
Basically it is the same idea than a python virtualenv with include-system-site-packages
set to false: never use what is provided
by the system and download everything in the exact version the
manifest tells you to.
<rant>On the whole, it seems they basically hate the idea of distro
packages, and seem intent on breaking them whenever people manage to
start to get them working.</rant>
Actually yes because they don't want to be bound to the version
provided by the distro (I will not enter the debate of whether it is
a good thing or not)
Nicolas
|
