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 <[EMAIL PROTECTED]> 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.