Re: emulators/qemu: "bmake package" fails

[Greg Troxel <gdt%lexort.com@localhost>]

Ottavio Caruso <ottavio2006-usenet2012%yahoo.com@localhost> writes:

> Update: I've done a
> bmake PKG_OPTIONS.qemu="-sdl" package
>
> and unfortunately I got exactly the same result as earlier.
>
> What I don't understand is why the install/package stage insists on
> creating these files:
> qemu-aarch64_be
> qemu-hppa
> qemu-nios2
> qemu-pr-helper
> qemu-riscv32
> qemu-riscv64
> qemu-tilegx
> qemu-xtensa
> qemu-xtensaeb
>
> I've done a grep of these names on both PLIST and PLIST.Linux but
> they're not there. I don't know where these targets come from.

PLIST does not control what's Built.   The control is in the makefiles
provided by upstream.

> So I think this is not a problem with PLIST but in some of the many
> patches somewhere along the lines.

Stepping back, it's important to understand the big picture.

Upstream has a plan about which files should be produced and installed.
This is not always clearly thought about, explained or documented.  (I'm
not saying it is confused in this case, just that sometimes it is.)

pkgsrc controls the build with --enable-foo options etc.

Some packages files are produced.

> Would be interesting to see if somebody has recently compiled qemu on
> NetBSD and had the same problem.

unlikely.  I built pkgsrc head qemu 4.0.0 on May 11.  Probably a few
people built it when you reported problems and found that it built for them.


So my point is that you need to understand what upstream intends, and if
the files produced are the right ones.  The set you report does not seem
wrong.  Indeed, I would wonder why riscv32/64 are not produced on
NetBSD.  Sometimes there are hidden dependencies that cause this kind of
variation.  The next step is to make the PLIST (by OPSYS, and flags)
match what is produced, without breaking it on other situations.

>> Separately, you might "cvs up -A" in qemu and try the head version,
>> because it's only 5 weeks to the new stable.
>
> I can't do that because I've used git and I'm not sure one can change
> branch in a subdir. In hindsight, I'd use CVS next time.

Well, not sure you should depart git.  In fact splitting branches is
unsound.  It just often works.