[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libguestfs
Subject:    Re: [Libguestfs] Continuing the split (was: Let's split up the libguestfs git repo and tarballs)
From:       "Richard W.M. Jones" <rjones () redhat ! com>
Date:       2019-11-29 22:02:58
Message-ID: 20191129220258.GC3888 () redhat ! com
[Download RAW message or body]

On Fri, Nov 29, 2019 at 05:04:14PM +0100, Pino Toscano wrote:
> On Friday, 29 November 2019 13:09:47 CET Richard W.M. Jones wrote:
> > So, the difficulty of git submodules aside, we have now split off
> > virt-v2v and virt-p2v into separate projects.
> > 
> > I also yesterday split off the boot analysis tools into a repo which
> > is likely to be rarely used and which I'll probably not bother to
> > package in Fedora.
> > https://github.com/libguestfs/libguestfs-analysis-tools
> > 
> > Where do we go from here?
> 
> Before going on with splitting, I'd take a "pause" to review the status
> of the projects, after their split. Considering the work that was
> already done to split them, and various difficulties we faced, there is
> enough material to check what still need to be improved/fixed, as most
> probably the same issues will happen in case of further splits.
> 
> The biggest issue I see so far is the impossibility to build virt-v2v
> (the only split project that requires libguestfs) with an uninstalled
> version of libguestfs. I see (at least) two problems.
> 
> 1) building C programs.
> Usually this means having a .pc file for pkg-config in PKG_CONFIG_PATH,
> with headers and library in the location of that file.  An approach
> I've seen done is to create a -uninstalled.pc file with its paths
> pointing to the source/build directories, and making sure the path of
> that -uninstalled.pc file is in PKG_CONFIG_PATH (which ./run can do).
> I never tried to do this, I can give it a try on Monday to see how it
> works.
> 
> 2) building OCaml programs.
> It seems like ocamlfind.findlib has the possibility to locate modules
> in non-standard directories (see findlib.conf(5)), however I never
> tried that.  Most probably a certain file structure is expected, which
> is definitely not what we have right now.
> 
> IMHO solving (1) is definitely a must, otherwise there is no way to
> test new APIs outside of the repository with libguestfs (the library).
> Possibly also (2) is a must -- for example, earlier I added to the OCaml
> binding this:
> https://github.com/libguestfs/libguestfs/commit/4aa4edf972bc8df8869cdcaa4ab4f40b63a626cf
> the idea is to use it in virt-v2v (not for an important change anyway),
> however right now it is not possible.

All good points.  For OCaml I believe we can set OCAMLPATH (see also
findlib.conf(5) for various other environment variables) and that will
allow virt-v2v to do:

  ../libguestfs/run ./configure
  ../libguestfs/run make

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

_______________________________________________
Libguestfs mailing list
Libguestfs@redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs

[prev in list] [next in list] [prev in thread] [next in thread]