Libguestfs - May 2022 - FYI - virt-v2v 2.1 now requires libvirt-ocaml library

On 04/29/22 13:02, Richard W.M. Jones wrote:
> On Fri, Apr 29, 2022 at 12:16:38PM +0200, Laszlo Ersek wrote:
>> On 04/28/22 16:47, Richard W.M. Jones wrote:
>>>
>>> I just pushed this to the development branch:
>>>
>>>
https://github.com/libguestfs/virt-v2v/commit/3c4505c12a096409e34dd70b938de29b8c7f81f7
>>>
>>> It removes the bundled/libvirt-ocaml directly entirely, so
you'll need
>>> libvirt-ocaml installed to build virt-v2v.  The reason for doing
this
>>> is I got a bunch of Coverity warnings for libvirt-ocaml and I only
>>> want to fix them in one place.
>>
>> Can you please add a "run.in" script to the libvirt-ocaml
project root,
>> so that virt-v2v can be built against a just-built libvirt-ocaml git
>> worktree? Similar to "libnbd/run.in".
> 
> https://gitlab.com/libvirt/libvirt-ocaml/-/merge_requests/14
> 
> Can't push to my own project any more :-(
The project has been too successful for any single developer to keep
push access! ;)

Thank you for the patch; it's hairier that I thought it would be.

Interestingly, I had to run "make opt" in libvirt-ocaml (not just
"make") in order to get the CMXA files, which virt-v2v requires. Is
that
intentional?

"make" in the libvirt-ocaml project root means "make all"
("all" is the
first target in Makefile.in), then "make -C libvirt all" means, per
"libvirt/Makefile.in":

------
all: $(BYTE_TARGETS)

opt: $(OPT_TARGETS)
------

I'd expect "all" to build "all" (both bytecode and
native).

Anyway, now I can build virt-v2v again!

Laszlo

On Mon, May 02, 2022 at 09:16:30AM +0200, Laszlo Ersek
wrote:
> On 04/29/22 13:02, Richard W.M. Jones wrote:
> > On Fri, Apr 29, 2022 at 12:16:38PM +0200, Laszlo Ersek wrote:
> >> On 04/28/22 16:47, Richard W.M. Jones wrote:
> >>>
> >>> I just pushed this to the development branch:
> >>>
> >>>
https://github.com/libguestfs/virt-v2v/commit/3c4505c12a096409e34dd70b938de29b8c7f81f7
> >>>
> >>> It removes the bundled/libvirt-ocaml directly entirely, so
you'll need
> >>> libvirt-ocaml installed to build virt-v2v.  The reason for
doing this
> >>> is I got a bunch of Coverity warnings for libvirt-ocaml and I
only
> >>> want to fix them in one place.
> >>
> >> Can you please add a "run.in" script to the
libvirt-ocaml project root,
> >> so that virt-v2v can be built against a just-built libvirt-ocaml
git
> >> worktree? Similar to "libnbd/run.in".
> > 
> > https://gitlab.com/libvirt/libvirt-ocaml/-/merge_requests/14
> > 
> > Can't push to my own project any more :-(
> 
> The project has been too successful for any single developer to keep
> push access! ;)
> 
> Thank you for the patch; it's hairier that I thought it would be.
> 
> Interestingly, I had to run "make opt" in libvirt-ocaml (not just
> "make") in order to get the CMXA files, which virt-v2v requires.
Is that
> intentional?
It's a hangover from the very old build system (the project dates from
about 2007 and hasn't changed a lot in that time).  It was somewhat
common (in 2007) for there to be architectures that had only the
bytecode compiler, but they no longer exist; and the project doesn't
use automake so you cannot easily conditionalise parts of the
generated Makefile.
> "make" in the libvirt-ocaml project root means "make
all" ("all" is the
> first target in Makefile.in), then "make -C libvirt all" means,
per
> "libvirt/Makefile.in":
> 
> ------
> all: $(BYTE_TARGETS)
> 
> opt: $(OPT_TARGETS)
> ------
> 
> I'd expect "all" to build "all" (both bytecode and
native).
Yes, it's a bit of a mess.  Patches to update the build system welcome
of course ...

Rich.
> Anyway, now I can build virt-v2v again!
> 
> Laszlo
-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW