> > Out of curiosity, would it be totally out of the question to require
> > having gofmt installed (not for 4.14, but in the future)? I ask because
> > I haven't seen it discussed one way or the other.
>
> I think I’d like to try to avoid it, unless / until we have a “core
> component” written i
> On Jun 8, 2020, at 12:16 PM, Ian Jackson wrote:
>
> George Dunlap writes ("Re: [PATCH v2 1/5] libxl: Generate golang bindings in
> libxl Makefile"):
>> So as written this turns out not to work correctly: `gengotypes.py` spits
>> out syntactically valid
George Dunlap writes ("Re: [PATCH v2 1/5] libxl: Generate golang bindings in
libxl Makefile"):
> 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 st
> On Jun 4, 2020, at 7:29 PM, Nick Rosbrook wrote:
>
>> 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
>> so
> On May 26, 2020, at 11:16 PM, George Dunlap 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 dependen
