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 <[email protected]> wrote: >>> >>> >>> >>>> On Jul 19, 2019, at 8:34 AM, Nicolas Belouin <[email protected]> >>>> 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 <[email protected]> >>>>> Signed-off-by: George Dunlap <[email protected]> >>>>> --- >>>>> 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. <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> -George _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
