Re: [Xen-devel] [PATCH] golang/xenlight: Add libxl_utils support

[Nicolas Belouin <nicolas.belouin@xxxxxxxxx>]

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).

Nicolas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel