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: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v3 4/5] tests/uefi-test-tools: add build scripts
Date: Tue, 5 Feb 2019 11:36:26 -0500

On Tue, Feb 05, 2019 at 09:49:57AM +0100, Laszlo Ersek wrote:
> 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.)

Thanks!

> 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.

That's true in that it's just a test.

> 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".

Yep that's true too.

> >>> 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

Interesting, thanks for sharing.

-- 
MST



reply via email to

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