Re: [PATCH v2 1/5] libxl: Generate golang bindings in libxl Makefile

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On May 26, 2020, at 11:16 PM, George Dunlap <george.dunlap@xxxxxxxxxx> wrote:
> 
> The generated golang bindings (types.gen.go and helpers.gen.go) are
> left checked in so that they can be fetched from xenbits using the
> golang tooling.  This means that they must be updated whenever
> libxl_types.idl (or other dependencies) are updated.  However, the
> golang bindings are only built optionally; we can't assume that anyone
> updating libxl_types.idl will also descend into the tools/golang tree
> to re-generate the bindings.
> 
> Fix this by re-generating the golang bindings from the libxl Makefile
> when the IDL dependencies are updated, so that anyone who updates
> libxl_types.idl will also end up updating the golang generated files
> as well.
> 
> - Make a variable for the generated files, and a target in
>   xenlight/Makefile which will only re-generate the files.
> 
> - Add a target in libxl/Makefile to call external idl generation
>   targets (currently only golang).

So as written this turns out not to work correctly:  `gengotypes.py` spits out 
syntactically valid but unformatted Go code, and then runs `go fmt` on it to 
get the right style (including tabs, &c).  But the error code of `go fmt` isn’t 
checked; so on a system without go installed, if the build system decides it 
needs to re-run `gengotypes.py` for whatever reason, the build succeeds but the 
tree ends up “dirtied” with an unformatted version fo the generated text.

The simplest short-term way to fix this would be to remove the `go fmt` call 
from `gengotypes.py`.  It’s actually relatively unusual for generated code to 
look pretty (or even be looked at).  We could also consider adding in some 
“manual” formatting in gengotypes.py, like indentation, so that it doesn’t look 
too terrible.

Nick, do you have time to work on a patch like that?

 -George