> On Apr 23, 2020, at 12:27 PM, Ian Jackson <ian.jack...@citrix.com> 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.
-George
