[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries |
Date: |
Sun, 30 Jun 2013 17:56:50 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 |
Am 30.06.2013 17:36, schrieb Michael Tokarev:
> 30.06.2013 19:28, Andreas Färber wrote:
>> Am 18.06.2013 19:34, schrieb Michael Tokarev:
>>> The following working patchset demonstrates a one step to plugins system:
>>> 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 Paolo
>> stashed most of that into common-obj-y and obj-y for simplicity.
>
> I don't understand. I for one like to see a plugins system used in qemu,
> 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.
>
> 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
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries, Michael Tokarev, 2013/06/30
Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries, Andreas Färber, 2013/06/30