Re: [Libguestfs] 1.39 proposal: Let's split up the libguestfs git repo and tarballs
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
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)