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: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH] Add CONFIG_QEMU_TIMER to handle qemu-timer-common.o dep
Date: Tue, 30 Aug 2011 19:37:27 +0000

On Tue, Aug 30, 2011 at 9:22 AM, Stefan Hajnoczi <address@hidden> 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.
>
> 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.

I don't have a strong preference here. In theory each object could
depend on multiple other objects, an explicit dependency approach of
course works but it may become heavyweight.

We could also divide QEMU into core libraries and support libraries
(which may or may not be used by core libraries). Core libraries would
be handled with the obj-y method, support libraries with traditional
AR libraries. That would handle multiple linking issues I think.



reply via email to

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