Re: [PATCH] libxl: avoid golang building without CONFIG_GOLANG=y

[George Dunlap <George.Dunlap@xxxxxxxxxx>]

> On Aug 26, 2020, at 8:41 AM, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 25.08.2020 12:37, George Dunlap wrote:
>> As an explanation, there are a combination of things. You proposed A (remove 
>> the dependency), Ian proposed B (use move-if-changed), but we’re hoping to 
>> do C (have an external tree) before the next release.  I haven’t had the 
>> time to look into either B or C (nor, unfortunately, to review Nick’s 
>> submissions to other parts of the code — sorry Nick!); but I’ve still been 
>> reluctant to go for A.
>> 
>> I think basically, unless someone is ready to tackle B or C immediately, we 
>> should just check in Jan’s fix (or probably better, just revert the patch 
>> that introduced the dependency).  It will be annoying to have to potentially 
>> fix up the generated golang bindings, but that puts the incentives in the 
>> right place.
> 
> One additional aspect to consider is that I ran into the issue actually
> in a 4.14 tree (because it just so happened that the timestamps of the
> involved files were "right" for the problem to be hit), i.e. whatever
> we decide to do will also end up needing backporting. To me this looks
> to make A less attractive.

I don’t understand why?  If it’s a regression in 4.14 functionality, we have to 
backport something to fix it one way or another.

If we were going to leave the functionality the way it is, it might make sense 
to make it so that the dependency was triggered only on staging/master; the 
goal, after all, was to make sure that the generated files were updated when 
libxl_types.idl was updated during development.

BTW, one way to prevent this from happening would be to add a version of the 
build to the Gitlab CI loop which would build out-of-tree and fail in a similar 
manner.  If there had been such a test, this change would have been reverted 
immediately.

 -George