[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries |
Date: |
Mon, 01 Jul 2013 17:20:42 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 |
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
- Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries, Stefan Hajnoczi, 2013/07/01
- Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries, Paolo Bonzini, 2013/07/01
- Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries, Paolo Bonzini, 2013/07/01
- Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries, Michael Tokarev, 2013/07/01
- Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries, Andreas Färber, 2013/07/01
- Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries, Michael Tokarev, 2013/07/01
- Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries, Paolo Bonzini, 2013/07/01
- Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries, Michael Tokarev, 2013/07/01
- Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries,
Paolo Bonzini <=
- Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries, Michael Tokarev, 2013/07/01