[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Golang Xen packages and the golang packaging system

  • To: Ian Jackson <Ian.Jackson@xxxxxxxxxx>
  • From: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • Date: Thu, 23 Apr 2020 17:22:33 +0000
  • Accept-language: en-GB, en-US
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=George.Dunlap@xxxxxxxxxx; spf=Pass smtp.mailfrom=George.Dunlap@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Nick Rosbrook <rosbrookn@xxxxxxxxx>
  • Delivery-date: Thu, 23 Apr 2020 17:22:48 +0000
  • Ironport-sdr: /qzOoBD1WyV3+KRJQD94Vx/OmNKtjNdyBy9/vCbhkj2tQkdEEDAXgxIXXd7/UaxnkfdV2ybBeK 27kZlW4uvt7V+bTsc9LYjB/WOgC/7UTUeJZZePHl3Kahpm2fy8OCZu7KqW79lWAGrc3mFkOCx3 c6aUwuu+V6KniBWYWzMA78aRW9zQ3aDax8KLTs6EHwmvfu1HvqiSE86w+Qm1XuPNpvzuqzTeLv Z4HRly9ZFZKstHPqmpgHPWuWM5J28jTy68EE81uv+T7YE/1voEALzDGClsIg0y0dfussTB0rzv x84=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHWGL+431OGV0A6ZUWxyQX/eS/9b6iGcJeAgAAA0oCAAAYAAIAAXRsA
  • Thread-topic: Golang Xen packages and the golang packaging system

> On Apr 23, 2020, at 12:49 PM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
>> On Apr 23, 2020, at 12:27 PM, Ian Jackson <ian.jackson@xxxxxxxxxx> wrote:
>> Ian Jackson writes ("Re: Golang Xen packages and the golang packaging  
>> system"):
>>> This is quite unpleasant.  In particular, it makes a git tree out of
>>> output files.  What will we do when someone sends us patches to the
>>> bindings ?
>> Also, anyone who redistributes your proposed golang package is
>> violating our licence unless they ship a copy of xen.git[1] too, since
>> the golang package is not source code.
>> [1] Technically, a copy of the relevant parts will do.
> The “relevant parts” would primarily be gengotypes.py, right?  Oh, and I 
> guess libxl_test.idl and friends.  libxl_test.idl isn’t included in the 
> distribution either.
> I’m not an expert in the golang build system, but they generally seem to be 
> trying to keep the functionality simple (which of course, means if you want 
> to do anything non-basic, it’s incredibly complicated or completely 
> impossible).
> There’s a command, `go generate`, which we could use to run gengotypes.py to 
> generate the appropriate files.  But I’m not sure how to use that in a 
> practical way for this sort of package: it might end up that people wanting 
> to use the package would need to manually clone it, then manually run `go 
> generate` before manually building the package.
> Checking in the generated files means that someone can simply add 
> `golang.xenproject.org/xenlight` as a dependency (perhaps with a specific 
> version tag, like v4.14), and everything Just Works.
> Nick may have some ideas on how to use the golang build system more 
> effectively.

So, the following seems to work quite well actually:

mkdir vendor
ln -s vendor/golang.xenproject.org /usr/share/gocode/src/golang.xenproject.org
echo “golang.xenproject.org/xenlight” >> vendor/modules.txt
go build -mod=vendor

Using the above method, (say) redctl.git would build exactly the same on Xen 
4.14 as on Xen 4.15 (assuming redctl wasn’t using anything not available in 

I’m inclined to say we should start with just telling people to do that, and 
look at doing something else if we discover that’s not suitable for some reason.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.