[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 01/25] configure: We don't want to clean configu
Re: [Qemu-devel] [PATCH 01/25] configure: We don't want to clean configuration files
Tue, 17 Jul 2018 19:27:19 +0200
Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
Peter Maydell <address@hidden> wrote:
> On 17 July 2018 at 18:05, Juan Quintela <address@hidden> wrote:
>> Daniel P. Berrangé <address@hidden> wrote:
>>> On Tue, Jul 17, 2018 at 01:33:38PM +0200, Juan Quintela wrote:
>>>> If you don't want to compile everything, you configure
>>>> config-devices.mak. And then make clean remove it, and make will
>>>> create a default one without your configuration. Fix it by not
>>>> removing it.
>>>> Signed-off-by: Juan Quintela <address@hidden>
>>>> Makefile | 2 +-
>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>> diff --git a/Makefile b/Makefile
>>>> index 2da686be33..2ffbcde323 100644
>>>> --- a/Makefile
>>>> +++ b/Makefile
>>>> @@ -751,7 +751,7 @@ clean:
>>>> if test -d $$d; then $(MAKE) -C $$d $@ || exit 1; fi; \
>>>> rm -f $$d/qemu-options.def; \
>>>> - rm -f $(SUBDIR_DEVICES_MAK) config-all-devices.mak
>>>> + rm -f config-all-devices.mak
>>>> VERSION ?= $(shell cat VERSION)
>>> This feels wrong to me. If 'make' is creating config-devices.mak, then
>>> either 'make clean' or 'make distclean' must remove it. So if you remove
>>> it here, it should be added to distclean instead.
>> I can agree with putting it on distclean.
>> make don't put it there if it is already there. My use case is that I
>> have several build trees from the same source three:
>> - x86_64-softmmu with minimal set of devices (the ones that I use)
>> - x86_64-softmmu with everything under the sun
>> - everything that can be compiled in in fedora
>> for the 1st case, I am interested that it is fast, so I edit the
>> x86_64-softmmu/config-device.mak. But if I do a make clean for any
>> reason, I lost my changes.
> I think the problem here is that we're confused about whether
> config-devices.mak should be a user-editable file or just
> part of our build process. Personally I think we should go
> for the latter, ie if there are useful use cases that
> currently you need to edit the file to achieve, we should
> provide a better mechanism for doing them.
I agree with the better mechanism, but until them this is the only way
to "choose" what devices to compile in. It is a very bad mechanism, but
it is the only one that we have right now.
On a general level, for devices that are quite well isolated, it works
quite well. But for the rest of the things, it is kind of messy.
- No dependencies
So, if you look at the generated x86_64-softmmu/config-devices,mak,
you can see that we define CONFIG_SCSI=y at least three times
- No way to show that dependencies at the C level, so we can only
compile in/out at the file level
- simple things like pc-speaker, msmouse or vmport, you can't compile
out, because they are created by code, not by
On the other hand, sometimes it looks like I am the only user that use
this. The original reason for this was to be able to compile out
drivers that downstream don't care about. There were a couple of
intents to integrate with something like kernel kconfig, but I think
that we never end integrating anything from there.
[Qemu-devel] [PATCH 02/25] config: CONFIG_SERIAL* is already in pci.mak, Juan Quintela, 2018/07/17
[Qemu-devel] [PATCH 05/25] check: Only test ne2000 when it is compiled in, Juan Quintela, 2018/07/17
[Qemu-devel] [PATCH 06/25] check: Only test eepro100 when it is compiled in, Juan Quintela, 2018/07/17
[Qemu-devel] [PATCH 07/25] check: Only test pcnet when it is compiled in, Juan Quintela, 2018/07/17
[Qemu-devel] [PATCH 09/25] check: Only test es1370 when it is compiled in, Juan Quintela, 2018/07/17