From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34722) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gKTY2-00005I-2x for qemu-devel@nongnu.org; Wed, 07 Nov 2018 14:31:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gKTXk-0006Nu-DZ for qemu-devel@nongnu.org; Wed, 07 Nov 2018 14:31:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41684) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gKTXj-0005zr-NA for qemu-devel@nongnu.org; Wed, 07 Nov 2018 14:31:12 -0500 References: <20180924092120.GA30163@caravaggio> <7c2b477e-bdac-c887-2510-82fe04acdcfe@redhat.com> <87b22690-e39c-3b46-dcb4-f6abc3213142@redhat.com> <41ceda53-467e-32a1-8fa6-13f0f9c08ad1@redhat.com> <20181107154114.GC27585@caravaggio> <20181107192414.GH12503@habkost.net> From: Thomas Huth Message-ID: Date: Wed, 7 Nov 2018 20:30:57 +0100 MIME-Version: 1.0 In-Reply-To: <20181107192414.GH12503@habkost.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] QEMU and Kconfig List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Paolo Bonzini Cc: Samuel Ortiz , "Zhong, Yang" , Peter Maydell , QEMU Developers On 2018-11-07 20:24, Eduardo Habkost wrote: > On Wed, Nov 07, 2018 at 06:39:54PM +0100, Paolo Bonzini wrote: >> On 07/11/2018 16:41, Samuel Ortiz wrote: >>> - The Kconfig parser would be used to generate the equivalent of what= we >>> currently have under default-configs/ I think we would still have something like default-configs - but there would only be the bare minimum config switches in there, the rest would be pulled in by dependencies. We could then also even have multiple config directories: ./configs +-------/default-softmmu +-------/default-linux-user +-------/nemu (or lean-kvm or something similar) +... ... just my 0.02 =E2=82=AC, feel free to ignore that idea ;-) >> It would be used to generate config-devices.mak, instead of >> scripts/make_device_config.sh. My branch already had some Makefile >> integration. >> >>> - From a user's build perspective, there would be no noticeable >>> difference, ./configure && make. Internally, both steps will consum= e >>> the *.mak files generated by minikconf. >> >> Right. The only difference is that a user could do "./configure && ma= ke >> randconfig && make" and similar. >=20 > Also, I would like to eventually replace many ./configure options > with options read from a build configuration file. >=20 > Distributions often have huge ./configure command lines in their > QEMU packages, and they could be replaced by simple build > configuration files. >=20 > Having a mode that requires all build options to be specified > explicitly (instead of silently picking a default) would be > useful for distributions, too. I think we should maybe not mix host configuration (via ./configure) and the target configuration (via kconfig), should we? Thomas