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

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

George Dunlap writes ("Re: [PATCH 3/5] libxl: Generate golang bindings in libxl 
Makefile"):
> tools/Makefile:subdirs-all is implemented as a non-parallel for loop 
> executing over SUBDIRS-y; tools/golang comes after tools/libxl in that list, 
> and so tools/golang:all will never be called until after tools/libxl:all has 
> completed.  This invariant — that tools/golang/Makefile:all must not be 
> called until tools/libxl/Makefile:all has completed must be kept regardless 
> of this patch, since xenlight/Makefile:build depends on other output from 
> tools/libxl/Makefile:all.

I had not spotted this aspect of the situation.  But the toplevel
Makefile is parallel.  I think this means that make -C works between
different directories in tools/.

Provided no-one says `make all install' (which is a thing that people
expect to work but which is already badly broken).

> So as long as nothing else calls tools/libxl:all or tools/libxl:idl-external, 
> this should be safe.  We could add a comments near xenlight/Makefile:idl-gen 
> saying it must only be called from libxl/Makefile:idl-external; and to 
> libxl/Makefile:idl-external saying it must not be called recursively from 
> another Makefile.

So, err, I'm sold on the original patch, I think.

Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

I'll answer your other comments anyway:

> > Alternatively, move the generated golang files to tools/libxl maybe,
> > and perhaps leave symlinks behind.
> 
> Would that result in the files being accessible to the golang build tools at 
> https://xenbits.xenproject.org/git-http/xen.git/tools/golang/xenlight ?  If 
> not, it defeats the purpose of having the files checked into the tree.

Yes.  git can convey symlinks.  (I'm assuming that the golang build
tools fetch the git objects and do git checkout, rather than
trying to download individual raw files from gitweb...)

> > Or convert the whole (of tools/, maybe) to nonrecursive make using eg
> > subdirmk :-).  https://diziet.dreamwidth.org/5763.html
> 
> This isn’t really a practical suggestion: I don’t have time to refactor the 
> entire libxl Makefile tree, and certainly don’t have time by Friday.

Yes, it wasn't a serious suggestion.  Sorry that that apparently
wasn't clear.

Regards,
Ian.