On 27/06/19 14:23, Markus Armbruster wrote: > Paolo Bonzini <pbonz...@redhat.com> 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