On 07/08/20 16:02, Peter Maydell wrote: > On Fri, 7 Aug 2020 at 14:55, Markus Armbruster <arm...@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.