[Libguestfs] 1.39 proposal: Let's split up the libguestfs git repo and tarballs

[Richard W.M. Jones]

On Tue, Jul 02, 2019 at 09:32:26AM +0200, Pino Toscano wrote:
> On Monday, 1 July 2019 22:47:32 CEST Richard W.M. Jones wrote:
> > > > Does this mean we need to move immediately to a submodule if just
> > > > splitting virt-p2v, or copy code as you suggest?  Maybe not, because
> > > > you can imagine for just this project copying the code needed from the
> > > > common/ directory, and creating a new "mini-generator" for the project
> > > > which handles the little bits that need to be generated in virt-p2v.
> > > 
> > > I'm actually solving in a different way, i.e. avoiding altogether the
> > > generator for p2v stuff.
> > 
> > Hmm.  There are parts of the current generator that apply to virt-p2v.
> 
> Which ones? As I explained already, I found only two:
> - p2v_config.ml, which is entirely p2v-specific; when converted to
>   another way, it can be dropped without affecting the rest of the
>   generated sources of libguestfs
> - authors.ml, shared with libguestfs to generate the top-level AUTHORS
>   file; I did not work on that yet -- my idea for it is to simply
>   provide a static AUTHORS file for p2v, and generate the C source with
>   the authors (for the GTK about dialog) using a simple Perl script

Yes, those are the bits I mean.

> > Can we split those parts of the generator out to have a new generator
> > that only applies to p2v?  I find the generated config stuff useful,
> > and in fact have a non-upstream patch to enhance it some more.
> 
> While I find the generator great for all the repetitive stuff related
> to bindings and actions, I'd rather not statically generate files at
> "dist" time if possible.  For libguestfs still makes sense because:
> - it allows users to build even the C library without OCaml installed
> - generating the doc texts of the APIs takes "a lot", even 2 minutes
>   on fast machines, because of all the pod2text invocations
> - few files (AUTHORS, gobject/Makefile.inc) are needed to create a dist
>   tarball
> 
> OTOH, to me this static generation has few drawbacks:
> - generated files in dist tarballs, which makes it more tricky to patch
>   them
> - a slightly different workflow than other generated files (say C
>   sources from flex/bison/gperf)
> 
> In the case of p2v, I simply do not see the need for OCaml, neither at
> development time nor at simple tarball building time, and not even for
> a static generator in general.  The generated files (with the notable
> exception of the p2v-config.h file) can be quickly generated at build
> time, with no drawback needed.

If you've come up with a way to deal with it I'm sure it'll be fine.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html