qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu Makefile.target


From: J. Mayer
Subject: Re: [Qemu-devel] qemu Makefile.target
Date: Tue, 09 Oct 2007 11:43:51 +0200

On Mon, 2007-10-08 at 21:33 +0200, Stefan Weil wrote:
> Blue Swirl schrieb:
> > On 6/1/07, Stefan Weil <address@hidden> wrote:
> >> Wouldn't it be better to let the compiler create dependency files
> >> which make can read? I posted a patch some time ago and use it
> >> since many months for different QEMU target platforms.
> >
> > I don't know, the dependencies aren't changing very often.
> The current Makefile.target contains a lot of dependencies,
> and I think they change often, their number is growing and
> nevertheless they are far from being complete.
> 
> The appended patch removes most explicit dependencies and
> adds gcc flags which create dependency files during normal
> compilation (so they are always up-to-date).

I arrived to the same conclusion, that hand coded dependencies are
always bugged and/or incomplete. I then was to propose a similar patch
with a few small differences. As -MMD / -MP is a preprocessor option, it
seems more logical to add them in CPPFLAGS. The second difference is
that it seems better to use the following syntax to include dependency
files:
-include $(wildcard *.d)
-include $(wildcard */*.d)
(some also include /dev/null in the list then it's never empty...)

This patch has a great drawback; you are to recompile almost everything
any time you change vl.h or target-xxx/cpu.h, for example. This, imho,
should not prevent us to apply it but shows us that most headers should
be splitted in a better way. As an example, it seems strange to me to
declare all devices prototypes in vl.h when those declaration should
never be used outside of hw subdirectory, where all hardware devices
emulation related stuff should stay. I guess we could find a lot of
examples of declarations/prototypes globally exported but only used
locally. Fixing this would make the code cleaner and, as a side effect,
would avoid a lot of waste of time recompiling useless stuff when doing
changes in headers.

-- 
J. Mayer <address@hidden>
Never organized





reply via email to

[Prev in Thread] Current Thread [Next in Thread]