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

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> 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 (as 
documented here: https://github.com/golang/go/wiki/FileTreeDocumentation).  The 
files which are copied are specified by the PGKSOURCES variable in the makefile.

The purpose of building a binary during the normal “make” process is not 
actually to have a useable binary; it’s to detect any potential issues when you 
do the Xen build, rather than whenever you actually build a Go program for the 
first time (potentially on some end-user’s system).  And “detect any issues” 
attempts to use “go build” in the situation you expect to use it at run time 
(i.e., it copies PKGSOURCES to a local directory, then points GO_PATH at them, 
points to the locally-built libraries, and then runs a plain `go build`).  In 
this way it should, theoretically, catch any of the following errors:

* Syntax / whatever errors in the Go bindings themselves
* Mismatches between the Go bindings and libxl &c
* Missing system libraries
* Something not right in the installation path system

All that to say — the “real” way to enable a new file in the xenlight package 
is to add it to PKGSOURCES.

 -George

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