On 06/08/2020 21.13, Paolo Bonzini wrote: > This the more or less final version of the Meson conversion. Due to > the sheer size of the series you have been CCed only on the cover > letter. > > The series reaches the point where Makefile.target and unnest-vars > can be removed, and all builds become non-recursive. I have also > converted parts of the testsuite, notably qtest since it is needed > for fuzzing. What's left for _after_ the merge is: 1) unit tests; > 2) moving the rest of installation to meson (for which I have patches); > 3) moving feature detection from configure to meson. > > Things I still haven't tested: > - fuzzing > - non-x86/Linux builds > - static builds > - Docker and VM builds > > Things I have checked: > - x86 builds > - modules > - "make install" > - internal slirp/dtc/capstone. > > It should be more or less bisectable. I have not tried building > _all_ steps, but I have tried both before and after each major one. > > Build system rebuild rules seem to work reliably. > > After a week or quite intense rebasing, my impression is more or less > the same as last December: Meson looks more daunting, but it is actually > much nicer to work with. > > The diffstat so far is not very favorable, but remember that: > > 1) the series leaves quite a few nearly-obsolete bits in configure, > Makefile and rules.mak (over 200 lines only in the makefiles). > > 2) configure test conversion will be where meson really shines. I > included a couple examples just to show > > meson: convert VNC and dependent libraries to meson > 4 files changed, 44 insertions(+), 134 deletions(-) > > meson: move SDL and SDL-image detection to meson > 5 files changed, 30 insertions(+), 144 deletions(-) > > meson: replace create-config with meson configure_file > 6 files changed, 80 insertions(+), 168 deletions(-) > > 3) the idea behind using Makefile generators is to have stable > code written in a high-level language instead of Makefile magic > that tends to grow by accretion. So even though ninjatool is > large at 1000 lines of Python, it can already be considered mature > or even "done". It had only ~15 lines changed since the last post, > and whenever debugging meson.build issues looking at build.ninja has > always (literally!) been enough. > > Available on git://github.com/bonzini/qemu branch meson-poc-next.
I just threw your meson-poc-next branch at our CI systems. Observations: 1) If no meson is installed, configure quickly aborts with "ERROR: Meson not found. Use --meson=/path/to/meson|git|internal": https://gitlab.com/huth/qemu/-/jobs/675533520 Could you simply change it to default got git/internal instead (where is the difference between git and internal?), so that we do not have to add a --meson=xxx to all the CI jobs everywhere? 2) With --meson=git added, I also do not get much further: "./ui/meson.build:77:0: ERROR: Program 'keycodemapdb/tools/keymap-gen' not found" https://gitlab.com/huth/qemu/-/jobs/675546229 Any idea what's going wrong here? 3) macOS build fails in a different way: ../meson.build:1:0: ERROR: Value "gnu++03" for combo option "C++ language standard to use" is not one of the choices. Possible choices are: "none", "c++98", "c++03", "c++11", "c++14", "c++17", "c++1z", "c++2a", "gnu++11", "gnu++14", "gnu++17", "gnu++1z", "gnu++2a". A full log can be found at /private/var/folders/3y/l0z1x3693dl_8n0qybp4dqwh0000gn/T/cirrus-ci-build/build/meson-logs/meson-log.txt ERROR: meson setup failed https://cirrus-ci.com/task/6514035426328576 Maybe we should use gnu++11 for C++ code nowadays? ... we still used gnu++98 in the past since GCC 4.8 (from CentOS/RHEL 7) has only "experimental" support for c++11 ... but since we're soon (in less than a year) going to drop support for that anyway, maybe we could switch it now already to gnu++11 ... ? Thomas