> On Jul 21, 2020, at 1:35 AM, Nick Rosbrook <[email protected]> wrote: > > # Long-term home of the package > > Ian: Autogenerated stuff is becoming more annoying. > > Delete all the libxl auto-generated stuff from staging & master, and have > "output branch". > > The reason we have these in-tree is that otherwise you can't build *from > git* if you don't > have new enough versions of the right tools. > > Distribution: Make a repo on xenbits!
So thinking about this: The first plan I had was to have a script in tools/golang/xenlight (and/or the Makefile), which would be handed a directory, and would then: 1. Sync static files from tools/golang/xenlight into that directory 2. Run gengotypes.py, having the resulting generated files put into that directory 3. Run `git diff` in the target directory; if there are any changes, then automatically run `git commit` to check in the changes. That way you could just set up a cron job to sync things over on a regular basis. Thinking about GPL considerations, however, you’d also want to include libxl_types.idl and idl.py. And then of course, you should also include a way to build the generated code from those two. At which point… would it make sense to just move the package out to its separate repo entirely? I.e., have actual development happen in the repo which ends up being cloned in the end? Obviously there are nice things about having the code in the same repo; but there’s also something satisfying about being a full downstream. I was actually thinking it might make sense to put the repo at https://gitlab.com/xen-project/go-xenlight , to try out that as a development model. Any thoughts? -George
