[Top][All Lists]
[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
- Re: [Qemu-devel] [PATCH] build: introduce target CONFIG_ variables and use them for kvm,
Paolo Bonzini <=