[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
- Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first, Olaf Hering, 2020/10/20
- Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first, Philippe Mathieu-Daudé, 2020/10/20
- Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first, Olaf Hering, 2020/10/20
- Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first, Philippe Mathieu-Daudé, 2020/10/20
- Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first, Daniel P . Berrangé, 2020/10/20
- Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first, Philippe Mathieu-Daudé, 2020/10/20
- Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first, Laszlo Ersek, 2020/10/21
- Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first, Olaf Hering, 2020/10/21
- Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first,
Laszlo Ersek <=
- Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first, Daniel P . Berrangé, 2020/10/21
- Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first, Laszlo Ersek, 2020/10/21
Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first, Olaf Hering, 2020/10/20