Re: [XEN PATCH for-4.17 v5 16/17] tools/golang/xenlight: Rework gengotypes.py and generation of *.gen.go

[Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>]

On 14/10/2022 12:42, George Dunlap wrote:

On 14 Oct 2022, at 12:37, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx> wrote:

On 14/10/2022 12:24, George Dunlap wrote:

On 13 Oct 2022, at 16:00, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx> wrote:

On 13/10/2022 14:05, Anthony Perard wrote:

diff --git a/tools/golang/xenlight/gengotypes.py b/tools/golang/xenlight/gengotypes.py
index ac1cf060dd..ff4c2ad216 100644
--- a/tools/golang/xenlight/gengotypes.py
+++ b/tools/golang/xenlight/gengotypes.py
@@ -723,7 +723,13 @@ def xenlight_golang_fmt_name(name, exported = True):
return words[0] + ''.join(x.title() for x in words[1:])

if __name__ == '__main__':
+ if len(sys.argv) != 4:
+ print("Usage: gengotypes.py <idl> <types.gen.go> <helpers.gen.go>", file=sys.stderr)

This breaks with Py2.7. Needs a

from __future__ import print_function

inserting at the top.

Out of curiosity, did you notice this by inspection, or because you specifically tested Python 2.7, or because a system you were using is still actually using Python 2.7?

Xen's build system can't actually create a build which supports Py2 and
Py3, because xen.lowlevel.{xc,xs} only get built once.  It would be nice
to fix this, but -ETUITS, so we state a specific version in the specfile
and mock ensures there is no trace of the other one.

XenServer is in the process of trying to retire Py2, but it turns out
that Xen isn't actually fully Py3 clean yet, so we use Py2 for Xen.

The build breaks because the libxl build writes the .go files even when
we don't actually want go bindings in the end.

I think the generation code is looped in even when golang is disabled so that we can detect IDL changes during development, even on systems which don’t have golang installed.  In theory if libxl.idl doesn’t change, it shouldn’t trigger the build?  Alternately we could consider skipping the code generation on non-debug builds, since we only really need to detect changes during development.

This is a "clean" mock build, from a git archive'd tarball.  Any logic like this is going to trigger unconditionally.

It's not a problem IMO - writing out one extra text file is not the slow bit of a Xen build.

~Andrew