On 3/24/10, Juan Quintela <quint...@redhat.com> wrote: > Blue Swirl <blauwir...@gmail.com> wrote: > > Hi, > > > > Here's some planning for getting most files compiled as few times as > > possible. Comments and suggestions are welcome. > > > I took some thought about this at some point. Problems here start from > "Recursive Makefile condered Harmful (tm)". > > Look at how we jump through hops to be able to compile things in > one/other side. > > We have: > Makefile > Makefile.target (really lots of them, one for target) > Makefile.hw > Makefile.user > > If we had only a single Makefile, things in this department would be > much, much easier. And no, convert to a single Makefile is not trivial > either, but it would make things easier. > > Why do we have several Makefiles? Because we want to compile each file > with different options. > > Why do we need to abuse so much VPATH? Because we need to bring files > randomly from $(ROOT), $(ROOT)/hw $(ROOT)/$(TARGET).
Would it help if the Makefiles were scattered to each directory, for example instead of Makefile.hw we had hw/Makefile? > Problem here, there isn't a simple way to compile files for several > target just once (no way to put them). > > Our main copmile rule is: > > $(QEMU_PROG): $(obj-y) $(obj-$(TARGET_BASE_ARCH)-y) > $(call LINK,$(obj-y) $(obj-$(TARGET_BASE_ARCH)-y)) > > > (notice that things compiled in Makefile are trivial, they are already > compiled just once by definition, problems are for all the qemu's we > compile). > > We could change: $(obj-$(TARGET_BASE_ARCH)-y) to something like: > > OBJ-TARGET=s/.o/.$(TARGET_BASE_ARCH).o/ > > (I forgot the subst Makefile syntax), and have the: > > %.$(TARGET_BASE_ARCH).o: %.c > gcc $(TARGET_BASE_ARCH options) > > From there, as you suggested, we need some files that are not compiled > by architecture, they need to be compiled by board, well, we need to add > yet another level obj-$(TARGET_BOARD) or whatever. > > Notice that this is a lot of work, but you are needing the audit to be > able to compile only once. Problem just now is that there is not a > simple way to describe that information, with my proposal it gets > trivial to express: > > obj-$(CONFIG_FOO) += foo.o # You need this for everything > obj-mips-$(CONFIG_FOO) += foo.o # You need this for all mips boards > obj-malta-$(CONFIG_FOO) += foo.o # You need this for all mips malta board > > You still need to do some different magic from hw-32/64 but it could be > done this way. Once you did it this way, you now where the files are > (hw or target) and you can drop the VPATH tricks. > > Problem with this proposal is that it is not trivial to do in little > steps, and the real big advantages appear when you switch to a single > Makefile at the end. I may have missed something, but the compile process doesn't care about boards, because all boards for some architecture (and therefore all devices used by all boards) are linked to a single per-architecture executable. So why introduce the boards concept to Makefiles? > > vl.c: a lot of work. Maybe the CPUState stuff should be separated to a new > file. > > > That should just be a rule in Documentation. You can't but anything > else in vl.c. If you move anything out of vl.c (see timers work from > bonzini for example), you get a wild card for free commit bypassing > maintainers or some similar price :) Cleaning up vl.c would be great, but just for purpose of single compilation, it's enough to put the CPUState pieces to a target dependent file (cpu-common.c?) and compile the rest once by making TARGET_xxx conditional code unconditional. This may still be doable. > <rest of files> > > I haven't really looked at them at depth. > > I looked when I cleaned up the build system, I thought how to do the > next step (outlined before), but got sidetracked by other more urgent > things. Thanks for the comments.