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
