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 €, 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 consume >>> the *.mak files generated by minikconf. >> >> Right. The only difference is that a user could do "./configure && make >> randconfig && make" and similar. > > Also, I would like to eventually replace many ./configure options > with options read from a build configuration file. > > Distributions often have huge ./configure command lines in their > QEMU packages, and they could be replaced by simple build > configuration files. > > 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