qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 4/5] tests/uefi-test-tools: add build scripts


From: Laszlo Ersek
Subject: Re: [Qemu-devel] [PATCH v3 4/5] tests/uefi-test-tools: add build scripts
Date: Tue, 5 Feb 2019 09:49:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1

On 02/04/19 22:55, Michael S. Tsirkin wrote:
> On Mon, Feb 04, 2019 at 08:46:33PM +0100, Philippe Mathieu-Daudé
> wrote:
>> Hi Michael,
>>
>> On 2/4/19 8:32 PM,  Michael S. Tsirkin wrote:

>>> And question would be what if someone wanted a reproducible
>>> build of QEMU, what would be the right way to do it?
>>
>> This question deserves his own thread :)
>
> Sure.

(I don't know enough to comment on this sensibly; so I'm only following
up to show that I'm not willfully ignoring the topic.)

What constitutes a "QEMU build" in this context?

If it means the sum of artifacts that get installed by "make install",
then the current patch set doesn't factor into that at all.

If it means something else, then "it depends". For example,
"genisoimage" and "mkdosfs" place pseudo-random / timestamp-based
identifiers into the images that they generate, and there's no way to
prevent at least "genisoimage" from doing that. Thus, if we consider
UEFI-bootable ISO images, rebuilt from zero, a part of a "reproducible
build", then the answer is "there's no right way until someone extends
genisoimage with some new cmdline options".

>>> Yes right now roms seems to be broken for an out of tree build but
>>> is that by design and should we add more examples of this?
>>
>> IMO having these tests build out-of-tree is easier than trying to
>> build various of the projects in roms/ out-of-tree. This would be a
>> good effort, but I'm not sure it is worth it with this series.
>> Eventually once we have a qtest using the bios-tables, we could spend
>> some time to make this script work out-of-tree.
>
> I'm not saying it's a blocker.

Regarding roms/edk2, we have to distinguish two sets of source code,
wrt. building out-of-tree.

- The firmware modules build just fine outside of the tree, and this
  patch set already puts that feature to use. (Namely, all the
  dependencies that the

    tests/uefi-test-tools/UefiTestToolsPkg/BiosTablesTest/BiosTablesTest.inf

  application pulls in from roms/edk2 are compiled outside of
  roms/edk2.)

- However, the native build utilities (in the

    roms/edk2/BaseTools

  subdirectory) that first have to be built natively, so that they can
  help produce the firmware executables from the firmware source, don't
  themselves build outside of that subdirectory. This is a genuine
  limitation of upstream edk2, as far as I can tell.

Thanks,
Laszlo



reply via email to

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