From: "andrzej zaborowski" <balrogg@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] How to split vl.h
Date: Thu, 1 Nov 2007 15:11:09 +0100 [thread overview]
Message-ID: <fb249edb0711010711l630c97beu4f6c439057a73669@mail.gmail.com> (raw)
In-Reply-To: <4729D583.407@mail.berlios.de>
Hi,
On 01/11/2007, Stefan Weil <weil@mail.berlios.de> 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
next prev parent reply other threads:[~2007-11-01 14:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 18:12 [Qemu-devel] How to split vl.h Blue Swirl
2007-10-31 19:35 ` Jocelyn Mayer
2007-10-31 23:06 ` Thiemo Seufer
2007-11-01 11:16 ` Fabrice Bellard
2007-11-01 13:32 ` Stefan Weil
2007-11-01 14:11 ` andrzej zaborowski [this message]
2007-11-04 8:48 ` Blue Swirl
2007-11-04 12:17 ` Paul Brook
2007-11-04 17:23 ` J. Mayer
2007-11-04 17:54 ` Paul Brook
2007-11-04 19:41 ` J. Mayer
2007-11-04 21:30 ` Paul Brook
2007-11-04 23:38 ` Thiemo Seufer
2007-11-04 18:06 ` Thiemo Seufer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb249edb0711010711l630c97beu4f6c439057a73669@mail.gmail.com \
--to=balrogg@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).