Am 03.06.2012 14:25, schrieb Paolo Bonzini: > One source of complexity in the QEMU source is that we have a very > shallow tree for a source code of over 750,000 lines of code. In > fact, one third of these lines alone is in one directory, hw/. > > As a prerequisite to cleaning up the structure, but as a worthwhile > step on its own, this patchset cleans up the build system so that > separate directories have their own Makefile snippet. As in the Linux > kernel build system, the overall build system is generally flat (in > the case of QEMU, with one recursive invocation per emulation target). > Subdirectories do not include complete Makefiles, instead they only host > the declarations for a few variables (common-obj-y, universal-obj-y, > obj-y, etc.). Definitions for all the directories are merged with a > little GNU Make magic (not much, only 20 lines). > > Two nice side effects are: > > - we can match the source tree and the object tree (for example the > per-target device models will be in XYZ-softmmu/hw, not in > XYZ-softmmu; those that are compiled once will be in hw/ rather > than in the root). > > - because the resolution of nested makefiles tracks the nested > directory, there is no need to use VPATH to find sources in > the hw/ and target-*/ directory. > > - there is a lot less Makefile programming (conditionals, addprefix, > etc.), replaced by only 20 lines in rules.mak and 1 in Makefile.objs. > > The series is entirely bisectable, and mostly consists of boring patches. > If the concept is accepted, I would like to get it in as soon as possible. > I have a few other cleanups on top (I stopped once I undid the diffstat > of this series :)), but they can be covered later. > > Thoughts, approvals, rejections?
As before, I dislike the use of the filename "Makefile" for files that are not self-contained. If make is called from that deep directory, it leads to undefined results. Either we must make sure through some clever ifeq'ery and a local "all" target that such an attempt fails, or better use a filename that is recognized by editors as Makefile syntax but not used by make without explicit -f, e.g., foo.mak. Note that I have been working on moving some more files from Makefile.target to Makefile.objs for compilation into libhw{32,64}. I'll defer that if people agree this is the way to restructure. Anthony had been talking about restructuring hw/ into a more Linux-like directory structure. Any update on that, Anthony? Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg