qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] How to split vl.h


From: andrzej zaborowski
Subject: Re: [Qemu-devel] How to split vl.h
Date: Thu, 1 Nov 2007 15:11:09 +0100

Hi,

On 01/11/2007, Stefan Weil <address@hidden> 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




reply via email to

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