On 7/19/19 11:24 AM, Nicolas Belouin wrote: > > > 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 <[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. > 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)
If that's a requirement, the distro can provide multiple concurrent versions. There are lots of places where build systems aren't allowed to access the internet. And distro packages provides lots of useful things: discoverability, filtering (some level of review has been done to make sure this code us useful / safe), maintenance (local patches / fixes can be applied if upstream disappears), decentralization (code is still available even if upstream goes down / deletes his repositories). I like Go as a language, but in this particular aspect, the core developers just seem to be insane. -George _______________________________________________ Xen-devel mailing list [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
