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

[Paolo Bonzini]

On 07/08/20 09:56, Markus Armbruster wrote:
> 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*
> 
> Have you run it through our CI?

Of course not. O:-)

> without even more weeks of intense rebasing.

FWIW there were only three hard rebases from 5.0 to 5.2:
qemu-storage-daemon (by far the hardest), linux-user's syscall_nr.h
generation, and fuzzing (easiest except it required conversion of qtest).  S

I would like to merge this on August 21st.  I hope to post a
"definitive" verion on August 14th, and hope to work with Peter the next
week on getting it to pass his tests.  Perhaps that's optimistic though.

Depending on when it's ready, I can pick up the series that gets rid of
Texinfo, if Peter and yourself don't want to learn Meson just for that.

Anyway, I think this is the no-return point: if people say no, I'm not
going to push it any further.  If people say yes, we'd better merge it
quickly and be done with it.

I do understand resistance.  It's a new tool replacing a 40-year-old
standard; build systems are not fancy; and there is a substantial sunken
cost.  All I can answer is that the line between sunken cost and
Stockholm syndrome is a fine one.  I cannot say this stuff has been
*fun*, but at least the debugging was refreshing compared to Makefiles.
 Again not a very high bar, but it's something.

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

Some oldish numbers:

                                 before    after
----------------------------------------------------
../configure                     18s       43s
../configure && make -j18        169s      172s
make -j18 (do nothing)           4s        4s
make -j4 (do nothing)            6.5s      4s
touch ../configure && make -j18  52s       62s (does nothing in make)
touch ../configure && make -j4   71s       62s (does nothing in make)
make clean                       19s       2s
make -j18 clean                  3.5s      2s
----------------------------------------------------
ninja -j18 (do nothing)                    1s
ninja -t clean                             2s
ninja -j18                                 96s (43s+96s=139s)

../configure becomes slower because minikconf.py moved from Make to
configure time, and because it has to generate the massive Makefile
which it didn't do before.  In fact it generates the build rules twice:
Meson first generates build.ninja, and then ninjatool turns it into
Makefile.ninja.

Most of the time is recouped during Make though, and a do nothing "make"
become faster, especially at lower -j.  This is expected because the
massive Makefile (while producing essentially the same rules as before)
is parsed directly by Make, without having to execute complex Make
macros.  It is more visible at lower -j because parsing the
non-recursive Makefile is serial, while the current build system uses
recursive Makefiles for which the work can be parallelized.

ninja is quite a bit faster than Make.  It also stores a binary
representation of build.ninja, so its do-nothing times are better.  We
can think of switching to it for the main build, once all tests are
converted to Meson.  Advantage: it lets us kill large swaths of
ninjatool; disadvantage: it introduces an extra dependency.  Even before
that, developers will be free to alternate between make and ninja.  I
haven't bothered so far, but then my machine does -j18 and not everyone
has that luxury.

tl;dr: for now, not much, but it can only improve.  This is consistent
with this series reaching the "worst mergeable state".  My objective was
only maintainability and not performance (without regressing on that front)

Another useful feature, that can be used more in the future, is
integration with external tools such as sparse (now) and clang's static
analyzer (later).  This is because ninja (and ninjatool) are able to
produce a compile_commands.json file that summarizes how to produce the
object files for the whole build.

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

Looking back at the goals:

- "it should remain trivial to do things that used to be trivial":
achieved though the syntax is more complicated.

- it should be "easy to do things that are a matter of cut-and-paste
from something that already exist": that would be for example adding a
new target, or new tools to contrib.  I added AVR and RX for this rebase
and it was the least of the problems, so I'd say achieved.

- "it should be possible to modify meson.build without knowing [details
of the QEMU build system such as ninjatool]": achieved.

- it should be "possible to do everything else".  Of course some parts
of meson.build (QAPI, tracetool, modules and the building the emulator
binaries) are complex.  The only part that is worse than before is the
forwarding "trace.h" headers (patch 4).  I have actually thought of a
way to fix that, but I am not 100% sure it works so I don't plan on
doing it before the merge.

- "drop Makefile magic in favor of build rule generators written in
high-level languages": achieved

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

Yes, that's my point expressed in a succinct way.

Paolo