qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] Add CONFIG_QEMU_TIMER to handle qemu-timer-comm


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] Add CONFIG_QEMU_TIMER to handle qemu-timer-common.o dep
Date: Tue, 30 Aug 2011 09:17:24 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

On 08/30/2011 04:22 AM, Stefan Hajnoczi wrote:
On Mon, Aug 29, 2011 at 8:27 PM, Michael Roth<address@hidden>  wrote:
@@ -380,7 +381,6 @@ else
  trace-obj-y = trace.o
  ifeq ($(TRACE_BACKEND),simple)
  trace-obj-y += simpletrace.o
-user-obj-y += qemu-timer-common.o
  endif
  endif

Now that we have a concrete patch to look at I think this approach is
problematic.  There are several subsystems in QEMU which might be
built outside the main qemu binary for qemu-io, qemu-img, qemu-ga,
etc.

Er, but qemu-timer cannot possibly be used by qemu-io/qemu-img.

Is this all dummy magic in order to let qemu-io build even though simple tracing won't work?

Perhaps we should look at making the tracing backends dynamic instead of static?

Regards,

Anthony Liguori


Each subsystem should explicitly include its dependencies (e.g.
subsys-obj-y += qemu-timer-common.o or subsys-obj-y +=
$(more-fundamental-subsys)) so that it can be easily used by a target.
  If this is not done then there are two disadvantages:
1. We spray dependency information across the makefiles instead of
keeping them contained with the subsystem that has the dependency
requirement.
2. We duplicate the dependencies across each target in the form of
conditional objects:
x-obj-$(CONFIG_MY_DEPENDENCY) += ...

If QEMU is split up into libraries then having an explicit list of
dependencies for each subsystem will be very useful, whereas the
CONFIG_* approach doesn't collect that information in one place.

So I think explicit subsys-obj-y += qemu-timer-common.o together with
$(sort) during the link stage actually allows for a cleaner build
system.  I prefer that approach.

Stefan





reply via email to

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