2014-07-12 14:00 GMT+04:00 Richard W.M. Jones <rjones@redhat.com>:> It depends entirely on what the Linux kernel and tools can do. If > there are properly maintained Linux tools for resizing BSD slices, > then it should be no problem to add this. > > Compare with 'ntfsresize', where ntfs-3g exists and is well-maintained > and available in the majority of Linux distros. >As i see parted have ability to work with bsd slices, also linux kernel have bsd partition support. Bud i don't know about resize file system.>> I think that golang bindings need separate repo, may be autogenerate >> bindings and push resulted files to separate github repo.... In this >> case peaples can do go get github.com/libguestfs/go-libguestfs and >> have a package. And build it with or without CGO_ENABLED (static or >> dynamic). But in case of autogenerated binding i don't know how to >> write docs and keep it sync with code... > > The trouble with a separate repository is that it would quickly go out > of date compared to the current API. That's why we strongly prefer to > keep the bindings in tree (and of course generated, not hand-written). >But why? As i understand binding updated when new release comes, not the big problem generate code go bindings and upload it to github, or some git repo, got get able to install package from git repos...> Can we not build some kind of tarball? A similar situation was > proposed for accepting libguestfs bindings into Python pypi.Tarball not suitable for go... Also for docs - you can create in repo file doc.go and provide interfaces/function names with extracted portion of comments from headers. This is enough to generate some docs about exiting functions... -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru
On Sun, Jul 13, 2014 at 11:11:54PM +0400, Vasiliy Tolstov wrote:> But why? As i understand binding updated when new release comes, not > the big problem generate code go bindings and upload it to github, or > some git repo, got get able to install package from git repos...<rant> I guess we can add this to the process. It's a bit tedious that (again) golang defies conventional packaging. In Fedora, golang causes no end of trouble because it prevents, dangerously IMO, ordinary distro packaging. </rant> What does the git repo look like? Is there an example of one? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
2014-07-14 15:30 GMT+04:00 Richard W.M. Jones <rjones@redhat.com>:> <rant> > I guess we can add this to the process. It's a bit tedious that > (again) golang defies conventional packaging. In Fedora, golang > causes no end of trouble because it prevents, dangerously IMO, ordinary > distro packaging. > </rant> >The main problem in current binding that it does not have source code, only compile package file, and if i simple want to rebould package without CGO (static linking) or run local godoc to see docs i can't do that.> What does the git repo look like? Is there an example of one?Nothing special - put all go files (*.go) to dir and push it to repo. About docs - before each function in go file you need // FuncName document string where FuncName - function name, document string some docs about function. Nothing special. to compile with cgo you need on top of file something like: // #cgo CFLAGS: -DXXXXX=1 // #cgo LDFLAGS: -lguestfs // #include <libguestfs.h> import "C" -- Vasiliy Tolstov, e-mail: v.tolstov@selfip.ru jabber: vase@selfip.ru