qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel P . Berrangé
Subject: Re: [DRAFT PATCH 000/143] Meson integration for 5.2
Date: Fri, 7 Aug 2020 16:58:24 +0100
User-agent: Mutt/1.14.5 (2020-06-23)

On Fri, Aug 07, 2020 at 05:14:06PM +0200, Paolo Bonzini wrote:
> 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.

Using meson for submodules too is potentially appealing, as you can
then take advantage of Meson's subproject support. This makes it easy
for distro vendors to turn off building of the bundled pieces in favour
of the distro provided equivalent.

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

I was never entirely happy with the trace.h stuff even in "make".
Trying to maintain the "trace.h" name for every generated header
was probably a mistake in retrospect. it caused me so much pain
trying to get the "make" rules correct so that we resolved the
right trace.h in each case. I was deperately trying to avoid
updating the #include lines, but I'm not sure it was worth
it in the end. Would have been easier to just generate a unique
header file name for each dir and update the #includes.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]