I tried to build QEMU from git using latest Muon (thanks for adding "keyval" module support!), and met the new error - due to the difference of returning result of "current_build_dir()" function.
detected compiler gcc '12.2.1' (['cc']), linker ld.bfd configuring 'qemu', version: 7.1.50 warn importing unimplemented module 'sourceset' err '/home/xvilka/sources/qemu/build/config-host.mak' is not a file /home/xvilka/sources/qemu/meson.build:19:22: error in method module.load() 19 | config_host = keyval.load(meson.current_build_dir() / 'config-host.mak')
Are you sure that is the problem? It seems to me that this file is generated by qemu's
configurescript. I was able to get further building qemu by running
mkdir build cd build ../configure --meson=muon
configuregets to the actual meson invocation, it fails due to passing invalid arguments. After that you can run
muon setup buildfrom the project root as usual.
I was able to get pretty far with
muon setup -Dvfio_user_server=disabled -Dnettle=enabled build. The next big thing to implement is the sourceset module, which I am working on right now :)
Yes, you are right. Sorry, at that day I was too tired and forgot that QEMU uses
./configurefirst. I saw you also implemented the "sourceset" module, but there is a new problem:
warn dependency ['gnutls'] not found /home/xvilka/qemu/meson.build:1155:25: error unsupported dependency method 'config-tool' 1155 | method: 'config-tool', ^ /home/xvilka/qemu/meson.build:1154:14: error in function dependency() 1154 | gcrypt = dependency('libgcrypt', version: '>=1.8', ^
Muon does not support custom (non-pkgconfig) dependencies for the most part. IIRC there's a framework stub for it and one or two (threads?) is actually implemented...
Correct, although there is a pending patch that would cause the
methodto be effectively ignored. In this specific case, I was able to bypass this dependency check by using nettle instead of gcrypt (-Dnettle=enabled).
The above patch with some modifications was applied, which means that the gcrypt lookup should result in a not-found dependency without erroring.
Now it fails because there is no
--cross-fileconversely) in the
This is what it feeds as the
# Automatically generated by configure - do not modify [properties] [built-in options] c_args =  cpp_args =  objc_args =  c_link_args =  cpp_link_args =  [binaries] c = ['cc','-m64','-mcx16'] cpp = ['c++','-m64','-mcx16'] objc = ['clang','-m64','-mcx16'] ar = ['ar'] nm = ['nm'] pkgconfig = ['pkg-config'] ranlib = ['ranlib'] sdl2-config = ['sdl2-config'] strip = ['strip'] widl = ['widl'] windres = ['windres'] windmc = ['windmc']
~xvilka I'm pretty sure you can bypass that by running
muon setupdirectly. See my above comment
When configure gets to the actual meson invocation, it fails due to passing invalid arguments. After that you can run muon setup build from the project root as usual.
Since qemu drives meson with a somewhat complicated script that relies on meson's cli, I think qemu support would probably need either a meson cli compatibility layer or the qemu devs to explicitly handle muon. I originally was against it, but now think it would probably be in muon's best interests to implement the former. It is on my todo list.
~xvilka I have implemented a basic compatibility layer. Can you test and see how far you get building qemu? I'm wondering if it is possible without machine-file support.
It fails with missing
i18n, I will send a patch to QEMU shortly
meson.build:4:8: error module 'i18n' is unimplemented, If you would like to make your build files portable to muon, use `import('i18n', required: false)`, and then check the .found() method before use. 4 | i18n.gettext(meson.project_name(), ^ qemu/meson.build:3640:3: error in function subdir() 3640 | subdir('po') ^