[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: George Dunlap <George.Dunlap@xxxxxxxxxx>
  • From: Ian Jackson <ian.jackson@xxxxxxxxxx>
  • Date: Tue, 26 May 2020 17:57:06 +0100
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Nick Rosbrook <rosbrookn@xxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Tue, 26 May 2020 16:57:31 +0000
  • Ironport-sdr: Ed4zbgttKkGzIfaAMvpWOXhlhTutbzcPEmuDnZM8pbCvXqxKC4m9CSxobFnlIikgvFyroi9lQO cIgQ2WhxACHkxlhldfZXtDV0TRsJkHQT3Mnre6bKvtu4ABZzaL9M4ueaxcK55zf9cNCmhjG7dZ cpmm+vyxv3TdptcpeZTgzOIPgnV8avyYTQF23ztnakf7YA8myDfIHWDcNqBdtUkqfIYGPtGUsj YjnBWodCwkiP7xVXXMpxfjFn9VWFWpHy00YQ7z8W7fRmJL97Kd6HwRHesM5BWqtfdFLxB/wYj+ yCo=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

George Dunlap writes ("Re: [PATCH 3/5] libxl: Generate golang bindings in libxl 
> 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.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.