From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtJzm-00034t-OB for qemu-devel@nongnu.org; Sun, 30 Jun 2013 11:56:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UtJzl-0007Uc-TA for qemu-devel@nongnu.org; Sun, 30 Jun 2013 11:56:58 -0400 Received: from cantor2.suse.de ([195.135.220.15]:52456 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UtJzl-0007UY-Jr for qemu-devel@nongnu.org; Sun, 30 Jun 2013 11:56:57 -0400 Message-ID: <51D05542.5090901@suse.de> Date: Sun, 30 Jun 2013 17:56:50 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1371576844-28743-1-git-send-email-mjt@msgid.tls.msk.ru> <51D04EA6.6020806@suse.de> <51D05090.40304@msgid.tls.msk.ru> In-Reply-To: <51D05090.40304@msgid.tls.msk.ru> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: Paolo Bonzini , qemu-devel@nongnu.org, Peter Maydell Am 30.06.2013 17:36, schrieb Michael Tokarev: > 30.06.2013 19:28, Andreas F=E4rber wrote: >> Am 18.06.2013 19:34, schrieb Michael Tokarev: >>> The following working patchset demonstrates a one step to plugins sys= tem: >>> it moves various dependent libraries and stuff out from libs_softmmu = or >>> libs_tools to object-specific variables. >> >> We did have a more elaborate Makefile variable system before, but Paol= o >> stashed most of that into common-obj-y and obj-y for simplicity. >=20 > I don't understand. I for one like to see a plugins system used in qem= u, > and except of the build system everything else is easy (and even nice, > there's even no need to load all plugins at startup as was initially > suggested). But for this to work, we really need to separate libs > used only by plugins from the main lot, -- or else there's just no > reason to build plugins in the first place. >=20 > So, are you saying we should abandom this whole idea? Or that maybe > Paolo dislikes it (I think he expressed his interest here too)? I haven't read the whole thread yet, so count me confused too, including that Paolo didn't reply to that part of the message at all. Whenever the question of a plugin system came up, it was mostly about desperate attempts to try to sneak GPL-incompatible code into QEMU. I doubt that is the case here, so I am not generally opposed. I assume your interest is rather reducing packaging dependencies for headless installs etc.? The only thing I was pointing out for now is that with regards to our build system our ship seems to have a slingering course, with objects originally being grouped by functionality/scope, then thrown into a big pot, now apparently being picked apart again. And implicitly I was hinting that there are people with out-of-tree patchsets that constantly need to rebase on these Makefile changes, me finding a whole Makefile.objs as conflict much more confusing to resolve than a new file not compiling due to some CPUState or QOM code changes. Not saying you shouldn't apply changes for cool features, please just coordinate with Paolo to avoid unnecessary back-and-forth in the build system. Cheers, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg