From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IfO4B-0004Y5-GJ for qemu-devel@nongnu.org; Tue, 09 Oct 2007 19:00:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IfO49-0004V4-4X for qemu-devel@nongnu.org; Tue, 09 Oct 2007 19:00:42 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IfO48-0004Uq-Ui for qemu-devel@nongnu.org; Tue, 09 Oct 2007 19:00:40 -0400 Received: from owa.c2.net ([207.235.78.2] helo=email.c2.net) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IfO48-0001Hu-HN for qemu-devel@nongnu.org; Tue, 09 Oct 2007 19:00:40 -0400 Subject: Re: [Qemu-devel] qemu Makefile.target From: Thayne Harbaugh In-Reply-To: <1191923031.9976.75.camel@rapid> References: <46605E29.6000509@mail.berlios.de> <470A860C.3000709@mail.berlios.de> <1191923031.9976.75.camel@rapid> Content-Type: text/plain Date: Tue, 09 Oct 2007 16:53:17 -0600 Message-Id: <1191970397.31334.14.camel@phantasm.home.enterpriseandprosperity.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: thayne@c2.net, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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 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.