On 7/17/19 1:34 PM, Aleksandar Markovic wrote: > > Daniel, that is fine, I don't question that, I basically wanted to start a > talk > between us to clarify some things. Related to our situation in the field, > I have a sub-question to you: > > Let's say there is a build system with SDL 1.2, and not SDL 2.0. Should > QEMU refuse to build?
If the dependency is soft (when SDL 2.0 is available, we can compile more things than when it is not), then the build shouldn't fail, but your resulting binaries will not use SDL. For example, we treat librbd as a soft dependency: if it is available, you can build in Ceph support; if it is not, you lose out on that particular block format, but can still run guests locally. If the dependency is hard (when SDL 2.0 is unavailable, we cannot perform our job), then the build should fail. For example, we treat glib2 as a hard dependency: if it is unavailable, we can't implement our main loop, and there's really nothing left worth compiling. Some qemu dependencies are hard, some are soft. And your choice of configure options may further influence things (our KConfig setup may mean that some libraries are hard dependencies for one board type, but soft dependencies for others). Off-hand, I'd guess that SDL 2.0 should be a soft dependency (but if it is a hard dependency, patches to make it a soft dependency are welcome); if I'm right, then building when only SDL 1.2 is available should not fail, but also will not use SDL. But the presence or absence of SDL 1.2 on a build machine has no bearing on the real question of whether SDL 2.0 is a hard or soft dependency, now that the project has decided that SDL 2.0 is easy enough to obtain across all of the set of systems included in our documented list of minimum development setups. In short, if you want to build with SDL, you need to have SDL 2.0 available because we are not going to support builds against SDL 1.2 as a reasonable development target any longer; but having SDL 2.0 development libraries available does not preclude also keeping SDL 1.2 on the same machine for other reasons. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
