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 andPy3, because xen.lowlevel.{xc,xs} only get built once. It would be niceto fix this, but -ETUITS, so we state a specific version in the specfileand mock ensures there is no trace of the other one.XenServer is in the process of trying to retire Py2, but it turns outthat 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 whenwe 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.
-George |