Re: minimal "zero conf" build dockerfiles for fedora:latest and alpine:latest

[John Snow]

On 1/13/21 1:48 AM, Thomas Huth wrote:
> On 12/01/2021 23.37, John Snow wrote:
> > I wanted to know what the minimal setup required was to replicate the 
> > compilation instructions featured on 
> > https://www.qemu.org/download/#source
> [...]
>  >      pixman-devel \
>
> pixman is only required for the softmmu and tools targets. If you just 
> build the linux-user targets, you can even get rid of this.

Sure; the intent was to figure out what happens if you run the 
instructions from the website without explicitly disabling anything.

What will you get by default?

softmmu by default is probably a pretty reasonable thing to want to 
build, so I'd say pixman will have to stick around in our minimal 
dependency list for now; though if we were to translate this experiment 
to the website, it'd be worth noting that pixman is only required for 
some, but not all, binaries like you say.

(If there was some way to build softmmu without pixman by default, that 
would be pretty interesting, though. I suppose it would involve 
disabling all spice/vnc/graphics devices entirely? It doesn't seem 
tremendously important, but pixman does stick out as the lone very 
particular dependency for a minimal build.)

> [...]
> > Notes:
> >
> > - our configure file suggests bzip2 is an optional dependency (It's 
> > set to 'auto') but meson will error out if it is not present at 
> > configuration time:
> >
> >      ../pc-bios/meson.build:5:2: ERROR: Program 'bzip2' not found
>
> IIRC it's required for compressing the edk2 firmware images, so if you 
> compile without x86 and arm, you don't need it. Maybe it would be good 
> to add a check for this to the configure script, too?

It already is erroring out when meson runs, so I think it's probably 
fine. Just something to document.

> > - diffutils is required for the qapi-schema test, which runs at build 
> > time.
>
> We should maybe add a check for "diff" to the configure script?

It's in tests/qapi-schema/meson.build already, so I think it's sufficient.

> > - early on in the build process, an error "bash: find: command not 
> > found" can be seen, but it doesn't seem to cause a failure otherwise.
> >
> > - perl is not declared as a hard pre-requisite during configure time, 
> > but the build will error out if it is not present:
> >
> > [254/8314] Generating texture-blit-frag.h with a meson_exe.py custom 
> > command
> > FAILED: ui/shader/texture-blit-frag.h
> > /usr/bin/python3 /qemu-5.2.0/meson/meson.py --internal exe --capture 
> > ui/shader/texture-blit-frag.h -- /usr/bin/env perl 
> > /qemu-5.2.0/scripts/shaderinclude.pl ../ui/shader/texture-blit.frag
> > /usr/bin/env: ‘perl’: No such file or directory
>
> shaderinclude.pl seems to be pretty small, maybe it could be rewritten 
> in python?

Maybe; Paolo has replied to you as well, but this is just the first perl 
script that so happens to run. There might be others.

Drawing down on perl long-term is probably nice to do, but it's probably 
not a priority. For now, we have both perl and python as build 
dependencies. Let's document and move on.

> > - bash has to be installed explicitly. configure/meson do not check 
> > for it, but the build will fail if they aren't present.
>
> IIRC we were able to compile without bash before the meson conversion, 
> just some parts like the iotests needed the bash (at least that's why we 
> have a check for bash in tests/check-block.sh for example). Where is it 
> failing now?
>
> > - musl seems to work alright, but does throw a ton of warnings. I 
> > didn't actually run any tests, since they require more dependencies.
> >
> > - linux-user binaries can't be compiled because alpine's usage of 
> > musl; I didn't look much more closely.
>
> There were some related patches on the list recently, look for the 
> "Alpine Linux build fix and CI pipeline" patch series.

Glad to see someone else thought it would be worthwhile to support 
Alpine. There may be interesting use cases for building alpine QEMU 
containers that are configured for extremely particular use cases, to be 
deployed as a utility.

--js