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

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> 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.

Perfect timing: right before I drop off for two weeks of vacation.  I'm
excused!  *Maniacal laughter*

> 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.

Have you run it through our CI?

> 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.

Is it faster in common build scenarios?

> 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.

Not a particularly high bar to cross: our Makefiles are full of the kind
of black magic that keeps simple things simple (which is quite an
achievement; kudos!), and makes not-so-simple things really hard.

I think it's now time to plan the end game, preferably without even more
weeks of intense rebasing.

Do we have consensus to move forward with Meson?  If yes, I'd like to
propose to aim for merging as early as practical in the 5.2 cycle.
Rationale: rebasing build system changes on top of the Meson work is
probably easier than rebasing the Meson work, and avoids turning Paolo
into an overworked bottleneck.

In more detail:

1. Pick a tentative deadline.

2. Cover the testing gaps and get as much review as we can until then.
   Fix defects as we go.

3. If the known defects are expected to disrupt others too much, goto 1.
   Do not worry about unknown defects at this point.

4. Merge.

5. Deal with the fallout.

Opinions?

> 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.

The major drawback with generating code is usually having to debug the
generated code.  Your experience of not having to do that is
encouraging.

> Available on git://github.com/bonzini/qemu branch meson-poc-next.