qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules fir


From: Laszlo Ersek
Subject: Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first
Date: Wed, 21 Oct 2020 15:28:06 +0200

On 10/21/20 14:30, Olaf Hering wrote:
> Am Wed, 21 Oct 2020 14:05:18 +0200
> schrieb Laszlo Ersek <lersek@redhat.com>:
> 
>> Olaf: if you build QEMU from source, why don't you build SeaBIOS, iPXE,
>> edk2 etc *also* from their corresponding pristine upstream clones /
>> checkouts, using your own dedicated build scripts / packagings?
> 
> From my perspective it is like that:
> 
> I export xen/qemu/libivrt into an offline environment for building.

Makes sense.

> The "git clone/git export" is done without submodules, but each required 
> submodule is of course cloned/exported as well into the target directory.

The "roms/edk2" submodule of QEMU is *not required* for building QEMU.

> In the end it is me who decides what is required or not, which means only a 
> subset of all submodules need to be provided. The build process sees the 
> complete source, and as a result nothing needs to be downloaded.
> 
> With current master there are these two offending git commands. In my 
> environment they can not do anything but fail. I guess once the next qemu-X.Y 
> release becomes available as the usual "qemu-X.Y.tar.xz" release these git 
> commands will fail as well with 'make -C roms efirom'.

I can't fathom why someone would want to run "make -C roms efirom"
against a tarball release of QEMU. That command does not participate in
building QEMU proper. It participates in refreshing some binaries that
serve convenience and/or self-check purposes.

(In case of edk2, there isn't even a legal/licensing requirement for
distributing the source of the firmware, along with the binary. See
"pc-bios/edk2-licenses.txt".)

> As said elsewhere, the correct approach might be to check what is missing and 
> download only these submodules. This should take the existing configure knobs 
> into account.

The "make -C roms efirom" command was never meant to work in the
environment -- such as an offline environment -- in which you have been
running it. I have not once tested the build scripts like that.

I'm OK to review and regression-test patches to this end, but I'm not
interested in authoring them (nor in testing them in an offline env).

Thanks
Laszlo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]