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

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Jun 4, 2020, at 7:29 PM, Nick Rosbrook <rosbrookn@xxxxxxxxx> 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 
>> 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?
> 
> Yes, I have time to work on a quick patch for this. I'll see what it
> would take to add a bit of basic manual formatting, but of course the
> original purpose of using gofmt was to avoid re-creating formatting
> logic. I'll likely just remove the call to go fmt.
> 
> 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 in golang.  For one, if we added it as a core dependency, we’d need to 
be  backwards compatible to the oldest version of golang of distros on which we 
want to build; that would include  Debian oldstable, Ubuntu LTS, probably 
CentOS 7 at least, possibly CentOS 6, and so on.  If any of those didn’t have 
golang available, then we’d basically have to decide between dropping support 
for those distros, and making golang optional.

I don’t at the moment have a good feel for what other people in the community 
feel about this, but generally speaking being fanatically backwards compatible 
is an investment in the long-term ecosystem; keeping Xen *as a whole* building 
on older distros is an example of that.  (FWIW I don’t think we have an 
official rubric, but my starting point is that we should try to build on all 
still-supported major distros; that would include CentOS 6 until Q4 of 2020, if 
my quick Google search is correct.)

One advantage of making golang optional is that we don’t have to be quite so 
backwards compatible — up until we declare the feature “fully supported”, we 
can move the minimum required version forward at will if we want to rely on new 
features.

 -George