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

[Paolo Bonzini]

On 07/08/20 17:26, Peter Maydell wrote:
> For instance, I was just glancing through the Meson FAQ,
> and "tell the compiler not to use RTTI for C++" is apparently
> something that needed a change to Meson to support, which seems
> ridiculous.

I am not sure why they singled that out in the FAQ, but there's actually
an explanation for requiring a change to Meson: the Meson option takes
care of that for both Visual Studio and GCC.  If (as we do) you only
care about GCC, you can just add -Wno-exceptions just like you'd do with
Shell+make.

I agree that making it a FAQ is sort of ridiculous.

> This really feels like we're going to find ourselves
> in the future boxed into "we're using Meson, but we also need
> to do X, and Meson's opinion is 'nobody would want X', so we're
> stuck". This initial attempt at conversion already got stalled
> for a long time AFAIK because it took a long time to get a
> feature we wanted into Meson and then for Meson to do a
> release with the change in it. That seems like a bad sign to me.

I'd say it was mostly because I had other stuff to do.  Rebasing to a
new release needed me to have the right amount of free time (a lot) at
the right point of the release cycle (during freeze).

What you refer to is the fact that it took a long time for Meson to
declare the "keyval" module stable.  That module is what we use to load
.mak files from configure and minikconf into Meson, and it was a good
thing that it took a long time actually.

The initial version was called "kconfig", and the Meson developers were
worried about advertising something called "kconfig" when the only user
was QEMU and it was not even using kconfig.  In the end a user pointed
out that QEMU's config-host.mak file is in fact not a valid kconfig
files.  The Meson developers agreed to keep the code exactly the same,
just renaming the module from kconfig to keyval.  So I think they made
the right call.

This was the only feature that took time to stabilize, and I think they
made the right call.  For what it's worth, the list of things that were
contributed is as follows:

Completely new functionality:
* New "keyval" module
* New module "sourceset" to match source file lists against config

Extensions to existing constructs:
* configure_file(): Allow multiple inputs in command mode
* configure_file(): Add depfile argument

Interoperability:
* Support a NINJA environment variable
* mintro: include test protocol in introspection data
* Add TAP parser (which we don't use, it was only a bait for the
previous change :))

Paolo