Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries

["Andreas Färber" <afaerber@suse.de>]

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