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

[Paolo Bonzini <pbonzini@redhat.com>]

Il 01/07/2013 17:06, Michael Tokarev ha scritto:
> So instead of this, we may have in the top-level Makefile:
> 
>   obj-i386-y += hw/i386/msi.o hw/i386/irq.o hw/i386/kvm.o
> 
> Or, if you prefer programmatic expansion,
> 
>   list-i386-y += msi.o irq.o kvm.o
>   obj-i386-y += $(addprefix hw/i386/, $(list-i386-y))

If I have to choose my poison, I prefer the directory multiple times.
But both seem worse than what we have now?

> So the difference is just the addition of the pathnames,
> not the logic or ifdeffery.

Even after you factor in user-level vs. softmmu, tools, KVM vs. Xen vs.
TCG, and all that?

>> Conflicts in a small file are also way easier to solve, even if there
>> are more conflicting files.
> 
> Conflicts?  Which conflicts?  You mean merge conflicts?
> If yes, it does not really matter be it small file or large
> file.

When diff3 goes haywire because you're merging features back to a
4-year-old version, it matters a lot.

> (Again, the "half" here refers to the fact that some variables
> gets prefixed by the subdir automatically while some doesn't).

Which *-obj-y variables do not get prefixed?

> So before sending patches, can we at least agree (or not) that
> specifying paths explicitly (either using dir/obj.o or by calling
> addprefix) is not THAT bad or it should be avoided entirely?

addprefix is bad.  Specifying paths explicitly is not bad _per se_, but
if a directory is used to group related code, I think the Makefile
should also be separated.  For example in the future we may have Kconfig
files in hw/*, and of these three possibilities, (1) and (2) would be
worse than (3):

1) use a single huge Kconfig file for all devices, use a single
Makefile.objs;

2) split Kconfig, keep a single Makefile.objs file;

3) split both the Kconfig and the Makefile.objs files.

> (I dislike the recursive sub-make approach because when you have
> everything in one make it is much easier to see all dependencies
> and plan the work, instead of running a ton of submakes first,
> each checking if its own subdir is up to date).

I agree.  And again QEMU is doing half-this half-that, but I don't see
any alternative.

Paolo