Re: Golang Xen packages and the golang packaging system

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

George Dunlap writes ("Golang Xen packages and the golang packaging  system"):
> So currently, our build system will install the xenlight package into 
> $PREFIX/share/gocode/src/golang.xenproject.org/xenlight.  However, it 
> actually takes a bit of wrestling to get golang to use this location, and 
> makes it difficult to use shared code.  It would be nice if people could 
> simply add `golang.xenproject.org/xenlight` to their dependencies, and have 
> `go get` just DTRT.
> 
> This basically involves two things:
> 
> 1. Creating a publicly-accessible suitable git repo containing the golang 
> package(s)
> 
> 2. Causing `curl golang.xenproject.org/$PKGNAME` to return some HTML with the 
> following rune:
> 
> <meta name="go-import" content=“golang.xenproject.org git $URL”>
> 
> Where $URL points to the tree from #1.
> 
> We should probably also have some more human-friendly content in case someone 
> wanders there with a web browser.
> 
> “Suitable git tree” means:
> - That it contains just the bindings.  
...
> So what we’d need to do is have a process / hook somewhere which would, on 
> push to xenbits.xenproject.org/xen.git ’s master branch:
>  - Generate the bindings from the source code
>  - Copy these bindings into the git repo, replacing the old bindings entirely 
> (i.e., deleting files which don’t exist any more, adding new files)
>  - Running ‘git commit’, probably with information about the commit from 
> which this code has been generated
>  - Check to see if there is a new RELEASE-X.Y.Z tag and generate an 
> appropriate tag
>  - Push to the git repo in step #1 above

This is quite unpleasant.  In particular, it makes a git tree out of
output files.  What will we do when someone sends us patches to the
bindings ?

Can we not instead provide some metadata at the top level of xen.git
which tells golang how to run enough of our build system to build the
needed .go files ?

Ian.