From: Eric Blake <eblake@redhat.com>
To: "Aleksandar Markovic" <aleksandar.m.mail@gmail.com>,
"Daniel P. Berrangé" <berrange@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>, Gerd Hoffmann <kraxel@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [QUESTION] SDL 1.2 support
Date: Wed, 17 Jul 2019 13:57:41 -0500 [thread overview]
Message-ID: <5b6d1130-73fd-b7c7-28ef-f553d33972e0@redhat.com> (raw)
In-Reply-To: <CAL1e-=jvRnp9NBzuMjOjP_WgCxhDSUf4qCkswRvyrpGFPK6cHg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2272 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-07-17 18:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-16 11:17 [Qemu-devel] [QUESTION] SDL 1.2 support Aleksandar Markovic
2019-07-16 11:41 ` Peter Maydell
2019-07-16 17:48 ` Aleksandar Markovic
2019-07-16 18:30 ` Peter Maydell
2019-07-16 11:50 ` Daniel P. Berrangé
2019-07-16 11:54 ` Thomas Huth
2019-07-16 17:09 ` Aleksandar Markovic
2019-07-16 17:44 ` Daniel P. Berrangé
2019-07-16 18:06 ` Aleksandar Markovic
2019-07-16 18:16 ` Daniel P. Berrangé
2019-07-17 18:34 ` Aleksandar Markovic
2019-07-17 18:57 ` Eric Blake [this message]
2019-07-17 19:20 ` Aleksandar Markovic
2019-07-17 19:57 ` Eric Blake
2019-07-16 18:20 ` Philippe Mathieu-Daudé
2019-07-18 6:20 ` Philippe Mathieu-Daudé
2019-07-29 10:36 ` Philippe Mathieu-Daudé
2019-07-29 11:27 ` Aleksandar Markovic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b6d1130-73fd-b7c7-28ef-f553d33972e0@redhat.com \
--to=eblake@redhat.com \
--cc=aleksandar.m.mail@gmail.com \
--cc=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).