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.
