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

[Pino Toscano]

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

> 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.

-- 
Pino Toscano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20190702/0d468541/attachment.sig>