[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: Compile files only once: some planning
From: |
Blue Swirl |
Subject: |
[Qemu-devel] Re: Compile files only once: some planning |
Date: |
Wed, 24 Mar 2010 19:56:02 +0200 |
On 3/24/10, Juan Quintela <address@hidden> wrote:
> Blue Swirl <address@hidden> 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.
Re: [Qemu-devel] Re: Compile files only once: some planning, Jamie Lokier, 2010/03/24
[Qemu-devel] Re: Compile files only once: some planning, Paolo Bonzini, 2010/03/24