Re: [Qemu-devel] [PATCH 3/7] configure: integrate Meson in the build system

[Paolo Bonzini]

On 27/06/19 14:23, Markus Armbruster wrote:
> Paolo Bonzini <address@hidden> writes:
>> On 27/06/19 11:03, Daniel P. Berrangé wrote:
>> There are two parts of this.  One is practical and has to do with
>> supporting a step-by-step transition.  Using ninja2make makes it trivial
>> to have make build products that depend on meson build products, and
>> this way bottom up is a natural direction to do the conversion, which is
>> bottom up.  You'd start from libqemuutil.a and code generators (tracing
>> + QAPI), then go to the tools and the emulators.
> 
> *If* the conversion is too big a task to permit doing it all at once,
> then the step by step strategy you describe makes sense to me.
> 
> The trouble with step by step is running out of steam before the final
> step.  That would leave us worse off.  Even an overly protracted
> conversion would be bad.

Agreed.  But hey, Makefile.objs is 2000 lines of lists of files, it is
boring but it cannot take that long to convert.  So it's not really
about being _possible_ to do it all at once, it's mostly about the
manageability of conflicts.

> Thus, my standard question on any proposed step-by-step conversion:
> commitment to finishing it?  I'd be quite happy to take your word for
> it.

I cannot really make such a commitment now, but perhaps I can (or I and
someone else can) once a little more of the conversion is ready.
Especially QAPI and trace generators, since those are where most of the
magic resides.  I can try that since your reaction wasn't of total
disgust. :)

>> The second is a design decision that simplifying the Make/meson
>> integration is *not* a goal.  Rather the goals are: 1) making the
>> transition easier on developers; 2) avoiding magic in meson.build at all
>> costs.  More specifically:
>>
> Your plan confines new magic to "Makefile rules and external scripts".
> We'll get actual reduction only if we can retire or at least radically
> simplify them at some point.

But even before that, we'll get *practical* reduction if it hacking the
Makefile rules and external scripts becomes rare enough.  See for
example kconfig, where # of people hacking minikconf.py is much less
than # of people hacking default-configs.

> I'm more ambivalent on (1).  Yes, making the transition easier for
> developers is worth hiding a certain amount of magic out of their way.

It's especially worth during the transition.  Once Makefile.objs is gone
I agree we can afford more radical changes, but let's cross that bridge
when we get there.

>> I expect testing might also require some hand-holding, because "meson
>> test" does not integrate with "make -j" and to keep supporting our "make
>> check-*" targets.  However, until the make->ninja flag day we could
>> generate tap-driver Makefile rules from "meson introspect --tests"
>> output.  Basically I'm dropping Makefile magic in favor of build rule
>> generators are written in high-level languages.
> 
> A PoC for selected tests would be nice.

Fair enough.

> Ignorant question: could the switch to Meson enable doing less in
> configure?  It's big and sloooow.

It would be smaller since the DSL is more compact than shell scripts,
probably not much faster as the same tasks still have to be done.  But
perhaps in the future Meson can parallelize them, and then we'd get that
for free.

Paolo