Re: [DRAFT PATCH 000/143] Meson integration for 5.2

[Thomas Huth]

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