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

[Paolo Bonzini]

On 07/08/20 16:02, Peter Maydell wrote:
> On Fri, 7 Aug 2020 at 14:55, Markus Armbruster <armbru@redhat.com> wrote:
>> I'm notoriously conservative in my choice of tools, and GNU Make is a
>> much better tool than some people give it credit for, but I've long felt
>> we've pushed it beyond its limits.
> 
> The thing is, it feels somewhat like we're already pushing Meson beyond
> *its* limits instead...

We totally are pushing it *to* its limits, though I obviously disagree
with "beyond".  QEMU would certainly be one of the largest projects
using Meson.  In fact we had to add more than one new feature.

One important difference between Make and Meson is that Meson is by
design limited in what it can do.  The idea (which I think has served
them well) is that they want projects to show what they need and work
with them on how to build it.  So:

- with Make you can do everything, it just becomes harder and harder;

- with Meson you cannot do everything, plus you're using software that
is opinionated and conservative in some respects with respect to its
design decisions.  In exchange: 1) you can always propose to add
features to the upstream project like Marc-André and I did; 2) you don't
have to worry about the minute details of everything.

So that's what makes Shell+Make and Meson substantially different tools.

Stuff like automatically cloning git submodules will never be in Meson,
and we can keep Make forever as a small escape hatch for that.  However,
using Make as a Turing-complete language to build our own DSLs on top of
is just a bad idea.  Shell+Make can remain simply as a driver for
executing commands, which is what Make does best.

We also have parts that have effectively separate build systems: I have
no plans to convert the TCG tests at all, the firmware could be
converted to Meson or Autotools (yes I am serious :)) or left aside, and
so on.


That said, and going back to pushing Make beyond its limits, I am quite
positive that unnest-vars has to go even if the solution has some
disadvantages.  Meson is one solution, our own home-grown DSL and
Makefile generator could be another.  However, designing our own build
system DSL is not something I want to spend time on; I prefer to improve
Meson for every other project using it, it's better for the whole open
source development community.

The reason why I started thinking about the conversion is that every now
and then people entered fights against unnest-vars and I was wondering
how those fights would compare to Meson fights.  And the result, after
about one year of hacking on and off, is that---with one exception---it
never felt like I was fighting Meson or the Meson maintainers; any
adaptation or concession came naturally, or was even an improvement in
retrospect.

That one exception, the one thing that disappoints me of the whole
conversion, is the trace.h files.  The current solution is one of the
first parts I did of the conversion and I have never touched it since; I
think it can be improved (I can even think of two ways to do it), but I
don't really have the time to do it now.  But even that bit is just
ugly, not unmaintainable, and I really see nothing in the conversion
that is a step back for QEMU's long term maintainability and our ability
to develop new features.

/me gets off the soap box

Thanks,

Paolo

> (it can't do everything we want it to, we've
> already had to get at least one new feature added upstream for our benefit,
> and in other places we're having to change our existing conventions
> to placate Meson). This would be an easier sell if it was "this is all
> straightforward and Meson has all the functionality we need".
> 
> I admit that I'm partly feeling a bit more conservative about tooling
> right now because we just switched the docs to Sphinx and Sphinx has
> turned out to have some annoying problems we didn't foresee. So taking
> another tool from the Python universe isn't hugely appealing.
> 
> (This is not a 'nak'; I'm just expressing my unease.)

Yes, it's totally understandable.