qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/7] configure: integrate Meson in the build system
Date: Thu, 27 Jun 2019 14:27:58 +0100	[thread overview]
Message-ID: <20190627132758.GL12358@redhat.com> (raw)
In-Reply-To: <20190627131601.3zln6ywzewm35qvn@sirius.home.kraxel.org>

On Thu, Jun 27, 2019 at 03:16:01PM +0200, Gerd Hoffmann wrote:
>  Hi,
> 
> > Ok, I can understand that. I've been thinking about how we can switch
> > libvirt to use meson too, and trying to decide between meson being the
> > owner, calling out to make  vs keeping make as the owner and calling
> > out to meson. Ultimately to entirely banish make, autoconf, automake,
> > libtool, m4 & shell from our build system :-)
> > 
> > Despite thinking about an incremental conversion though, I was still
> > hoping libvirt would just have a single (largish) patch series to
> > do a complete conversion at a specific point in time.
> 
> Another possible approach would be to have two build systems.
> The traditional configure & make and the new meson & ninja.
> 
> Advantage is we don't have to worry about the transition and mixing &
> make + meson at all.
> 
> Disadvantage is the duplication.  That wouldn't be forever though.
> I'd expect we'll have one or maybe two releases with both build systems,
> then delete the make & configure.

Personally I strongly wish to avoid having two parallel build systems.
In several projects I've encountered with that I've ended up hitting
bugs where each build system produced different binary results  due to
the developers not putting the same changes into both build systems.

Prefer to only merge a new build system once there is confidence that
it is working, and then immediately delete the old one so as to avoid
bitrot & concentrate any bug fixing on the modern stuff.

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


  parent reply	other threads:[~2019-06-27 13:29 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-10 11:14 [Qemu-devel] [RFC PATCH 0/7] Proof of concept for Meson integration Paolo Bonzini
2019-06-10 11:14 ` [Qemu-devel] [PATCH 1/7] configure: do not include $(...) variables in config-host.mak Paolo Bonzini
2019-06-10 11:14 ` [Qemu-devel] [PATCH 2/7] configure: set $PYTHON to a full path Paolo Bonzini
2019-06-10 11:14 ` [Qemu-devel] [PATCH 3/7] configure: integrate Meson in the build system Paolo Bonzini
2019-06-26 17:34   ` Markus Armbruster
2019-06-27  8:52     ` Paolo Bonzini
2019-06-27  9:46     ` Christophe de Dinechin
2019-06-27  9:03   ` Daniel P. Berrangé
2019-06-27 10:16     ` Paolo Bonzini
2019-06-27 12:23       ` Markus Armbruster
2019-06-27 12:50         ` Daniel P. Berrangé
2019-06-27 12:57         ` Paolo Bonzini
2019-06-27 12:55       ` Daniel P. Berrangé
2019-06-27 13:16         ` Gerd Hoffmann
2019-06-27 13:20           ` Paolo Bonzini
2019-06-27 13:27           ` Daniel P. Berrangé [this message]
2019-06-10 11:14 ` [Qemu-devel] [PATCH 4/7] libvhost-user: convert to Meson Paolo Bonzini
2019-06-27  9:03   ` Markus Armbruster
2019-06-10 11:14 ` [Qemu-devel] [PATCH 5/7] vhost-user-blk: " Paolo Bonzini
2019-06-10 11:15 ` [Qemu-devel] [PATCH 6/7] vhost-user-scsi: " Paolo Bonzini
2019-06-27 11:23   ` Markus Armbruster
2019-06-27 12:31     ` Paolo Bonzini
2019-06-10 11:15 ` [Qemu-devel] [PATCH 7/7] rdmacm-mux: " Paolo Bonzini
2019-06-27 11:38   ` Markus Armbruster
2019-06-27 12:21     ` Paolo Bonzini
2019-06-10 12:33 ` [Qemu-devel] [RFC PATCH 0/7] Proof of concept for Meson integration no-reply
2019-06-10 12:36 ` no-reply
2019-06-10 12:40 ` no-reply
2019-06-27 12:39 ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190627132758.GL12358@redhat.com \
    --to=berrange@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).