Re: [Qemu-devel] qemu Makefile.target

[Thayne Harbaugh <thayne@c2.net>]

On Tue, 2007-10-09 at 11:43 +0200, J. Mayer wrote:
> On Mon, 2007-10-08 at 21:33 +0200, Stefan Weil wrote:
> > Blue Swirl schrieb:
> > > On 6/1/07, Stefan Weil <weil@mail.berlios.de> 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.

With the many features that I have been adding to our private branch the
dependencies are changing and I've been considering how to make the
dependencies more automated.

> > 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'm interested in seeing this, also.  I have begun building out new
features for linux-user emulation and auto-generating the dependencies
will be helpful - as well as ensure that the dependencies are
up-to-date.

>  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.

A similar example is linux-user/qemu.h.  I want to submit some patches
that will start breaking up the linux-user files.  The linux-user
emulation will benefit by breaking files up according to architecture
rather than #ifdef'ing all the archs in the same file.  If have also run
into problems with too many #include files causing collisions of
typedefs from system headers (yes, this indicates poorly constructed
system headers).

>  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.

I agree.