Hi, On 01/11/2007, Stefan Weil <[EMAIL PROTECTED]> wrote: > Fabrice Bellard schrieb: > > Blue Swirl wrote: > >> Hi, > >> > >> With the automatic dependency rule installed, modifying vl.h causes > >> all files to be recompiled. This is of course the correct action, but > >> it's a major slowdown for development too. > > There must be an option in the Makefile to disable the automatic > > dependency check. > From my own experience, I can tell that the automatic > dependency check is not really a problem, but makes > things much easier and safer (I used it for more than > a year now).
>From my experience I can tell that working with no automatic dependency checks is also not so bad, it was just a bit of getting used to it. Qemu is actually one of very few projects I've seen with no automatic dependency checks in the makefile, but it stopped being annoying after little time. The huge vl.h with all declarations in one file is also unlike all other projects but admittedly it's pretty comfortable (unless it forces you to rebuild whole world on every modification). So I don't mind if it stays the way it was until now, but I also welcome an overhaul. > > I never missed a Makefile option to disable it. Of course, > changes of vl.h are somehow annoying when they force > a rebuild of nearly everything. But in most cases I focus > on one target architecture (e.g. mipsel-softmmu), so > compilation takes not much time even when everything > is compiled. And you always can make a "touch *.o */*.o" > if you know what you do and want to prevent a new > compilation (or use a private modification of the Makefiles). > > Options make things more complicated - I don't think we need one here. Adding this particular option wouldn't be intrusive. > >> How should we split vl.h into smaller pieces? Give each device a > >> header file, like m48t59? What about other stuff exported from vl.c? > > The net result is that you will have dozens of header files with only > > one line in them as most devices only export one function. > So you can group headers - one header for network emulations, > one for graphics, ... The logical division is not so practical here, it will again mean rebuilding everything that uses graphics if one adapter changes. Maybe a more clever dependency tracking is possible similar to that in Linux or Elinks. > > We had this discussion about splitting vl.h before, and I > still think it would be good. > > > > Regards, > > > > Fabrice. > Regards > Stefan > > > > Regards