From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52139) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjBAT-0001f3-De for qemu-devel@nongnu.org; Thu, 13 Dec 2012 10:57:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TjBAN-00028O-Tk for qemu-devel@nongnu.org; Thu, 13 Dec 2012 10:57:49 -0500 Received: from db3ehsobe005.messaging.microsoft.com ([213.199.154.143]:34666 helo=db3outboundpool.messaging.microsoft.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjBAN-00028I-LR for qemu-devel@nongnu.org; Thu, 13 Dec 2012 10:57:43 -0500 Date: Thu, 13 Dec 2012 09:57:32 -0600 From: Scott Wood References: <1355360271.28445.25@snotra> <50C980B8.30407@redhat.com> <37C86D07-3E8D-43C6-AA5F-8714A6B43C64@suse.de> <50C9F16A.2070602@redhat.com> In-Reply-To: <50C9F16A.2070602@redhat.com> (from kraxel@redhat.com on Thu Dec 13 09:16:58 2012) Message-ID: <1355414252.14046.1@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Anthony Liguori , Alexander Graf , qemu-devel@nongnu.org On 12/13/2012 09:16:58 AM, Gerd Hoffmann wrote: > Hi, >=20 > >> A pretty central data structure in qemu (DisplayState / > >> DisplaySurface) carries a pixman image, not some module which can > >> easily be made optional. Just look at the tons of #ifdef'ery you > >> have to do to get this going. > > > > His point is that anything related to DisplayState should be > > optional. >=20 > We can try, but sprinkling #ifdefs all over the place isn't the way to > go. Separate any Display* stuff, say to display.[ch]. Include > display.h only when needed. Then not compiling the object files > will do the trick, and maybe one or two #ifdefs in vl.c. >=20 > At least in theory. In practice it probably needs some more cleanups =20 > so > it actually works. That's fine. This patch was more of a quick hack to show that it's =20 possible, and to start a conversation about whether a cleaner approach =20 would be accepted if the effort were spent on it. > And the "not compiling" part brings us back to the "easy way to strip > down qemu" part. I'd love to have something (kconfig?) which allows =20 > to > pick which device emulations, block formats, ... I wanna include into =20 > qemu. Yes, kconfig would be very nice. -Scott=