[Top][All Lists]

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

Re: [Qemu-devel] [QUESTION] SDL 1.2 support

From: Aleksandar Markovic
Subject: Re: [Qemu-devel] [QUESTION] SDL 1.2 support
Date: Wed, 17 Jul 2019 21:20:54 +0200

On Wed, Jul 17, 2019 at 8:57 PM Eric Blake <address@hidden> wrote:
> 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.

Eric, I truly appreciate your clarification.

But, does "configure" list somewhere unmet soft dependencies? (the
question is general, not looking at SDL only) Is there any other way for
an end user to have info on unmet dependencies (whether soft or hard),
other than see QEMU is not building, or something is not working in
QEMU run-time?


We had message "SDL 1.2 is going to be deprecated" in QEMU 3.0
"configure" and, if I remember well, in QEMU 3.1 as well. And now,
when we finally deprecated it, is it true that there is no message
whatsoever on systems with SDL 1.2 only?


> 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

reply via email to

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