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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.08.2020 12:33, George Dunlap wrote:
> 
> 
>> 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?

Because you and Nick made clear that it's not the right way to deal with
the situation, i.e. I only consider this a band aid.

>  If it’s a regression in 4.14 functionality, we have to backport something to 
> fix it one way or another.

Oh, yes, something will need backporting. But perhaps a more permanent
and/or appropriate solution?

> 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.

Not sure about this. For one, the out-of-tree aspect has got nothing
to do with it, I think. It's instead the read-only-ness of the
source file which matters. IOW I assume things would have worked
fine if I didn't keep my original source trees r/o at almost all
times (and hence the symlinks, when followed, make the files be
viewed as r/o in the build tree, too).

And then the timestamps matter, too. On a fresh clone (which is what
osstest uses afaik, and I guess which is also what's done in gitlab
CI), the two files quite likely would have matching ones, in which
case no re-build attempt would occur.

Jan