qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] build: introduce target CONFIG_ variables and u


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] build: introduce target CONFIG_ variables and use them for kvm
Date: Thu, 21 Jun 2012 14:31:33 +0200

(Sorry for breaking the thread).

> This avoids the problem associated with having multiple target specific files
> in a single directory with the current build system.

What is exactly the problem?

I saw something about dependencies, I think that should be solved with
something like

$(foreach var, $(nested-vars), $(eval -include $(patsubst %.o, %.d, $($(var)))))

at the very end of unnest-vars.

> We can eventually get rid of the hw/$BASE_ARCH/Makefiles.obj files too

The goal should be to limit hw/$BASE_ARCH/Makefile.objs to hardware
that is CPU-dependent and to board descriptions.

I _think_ (but I don't have a checkout at hand) that hardware like
virtio can use obj-$(CONFIG_VIRTIO) while staying in hw/Makefile.objs,
but it should really be the only case of target-dependent file in hw/.
 Everything else in hw/$BASE_ARCH should move to target-$BASE_ARCH/hw.
 The steps should be as follows:

1) Identify more groups of hardware that can be moved from
hw/$BASE_ARCH to libhw. Move them.

2) At this point, hw/$BASE_ARCH/Makefile.objs should only refer to a)
boards b) hardware that is CPU dependent c) KVM device models with
host dependencies. Move the sources to hw/$BASE_ARCH, possibly
hw/$BASE_ARCH/kvm, and remove the addprefix invocations from
hw/$BASE_ARCH/Makefile.objs.

3) Move hw/$BASE_ARCH to target-$BASE_ARCH/hw.

I think CONFIG_$BASE_ARCH is a bad idea because it violates the
modularity that Juan introduced together with the config-devices.mak
files.

Paolo



reply via email to

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