From: Juan Quintela <quintela@redhat.com>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] Re: Compile files only once: some planning
Date: Wed, 24 Mar 2010 10:17:27 +0100 [thread overview]
Message-ID: <m3aatycc48.fsf@trasno.mitica> (raw)
In-Reply-To: <f43fc5581003231443x5492dd7eve541fd8104170a60@mail.gmail.com> (Blue Swirl's message of "Tue, 23 Mar 2010 23:43:51 +0200")
Blue Swirl <blauwirbel@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).
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.
> 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 :)
<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.
Later, Juan.
next prev parent reply other threads:[~2010-03-24 9:18 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 21:43 [Qemu-devel] Compile files only once: some planning Blue Swirl
2010-03-24 9:17 ` Juan Quintela [this message]
2010-03-24 17:56 ` [Qemu-devel] " Blue Swirl
2010-03-24 19:28 ` Juan Quintela
2010-03-24 22:47 ` Paul Brook
2010-03-24 22:57 ` Anthony Liguori
2010-03-25 3:08 ` Jamie Lokier
2010-03-25 2:54 ` Jamie Lokier
2010-03-24 9:47 ` Paolo Bonzini
2010-03-24 11:19 ` Richard Henderson
2010-03-24 14:45 ` Paolo Bonzini
2010-03-24 14:56 ` Paul Brook
2010-03-24 16:18 ` Paolo Bonzini
2010-03-24 17:27 ` Paul Brook
2010-03-24 17:07 ` Richard Henderson
2010-03-24 20:12 ` Richard Henderson
2010-03-24 18:00 ` Blue Swirl
2010-03-24 19:39 ` Michael S. Tsirkin
2010-03-24 20:05 ` Blue Swirl
2010-03-24 20:08 ` Michael S. Tsirkin
2010-03-24 20:24 ` Blue Swirl
2010-03-24 20:24 ` Michael S. Tsirkin
2010-03-24 20:32 ` Blue Swirl
2010-03-24 20:28 ` Anthony Liguori
2010-03-24 21:00 ` Aurelien Jarno
2010-03-24 22:33 ` Paul Brook
2010-03-24 22:50 ` Anthony Liguori
2010-03-24 23:05 ` Paul Brook
2010-03-24 23:07 ` Anthony Liguori
2010-03-25 8:21 ` Michael S. Tsirkin
2010-03-25 12:01 ` Paul Brook
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3aatycc48.fsf@trasno.mitica \
--to=quintela@redhat.com \
--cc=blauwirbel@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.