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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Nick Rosbrook writes ("Re: [PATCH] libxl: avoid golang building without 
CONFIG_GOLANG=y"):
> Jan - is the problem specifically that a fresh clone,  or `git
> checkout`, etc. changes file timestamps in a way that triggers make to
> rebuild those targets? I have not used the move-if-changed approach
> before, but AFAICT that would be sufficient.

I don't think there is, from the point of view of the build system,
anything different about gengotypes than about any other in-tree
committed file which is updated using makefile rules based on only
other in-tree files and common utilities (eg, in this case, Python).

I guess using move-if-changed will probably fix this.

Jan: the reasons why this output file has to be committed are
complicated.  We've discussed them at length.  Ultimately the reason
is deliberate deficiencies[1] in golang.  Sadly this is the best of a
not-very-good set of options.

Ian.

[1] This is an extreme phrase, but justified I think.  The golang
designers have deliberately aimed at what they regard as "simplicity"
and one of the things they have "simplified" away (in their language
and in their package management and build tools) is the ability to
conveniently generate golang code at build time.  Committing the
generated code is the norm in the golang community.