All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Markus Armbruster <armbru@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: deprecation of in-tree builds
Date: Tue, 31 Mar 2020 13:50:30 +0100	[thread overview]
Message-ID: <20200331125030.GG353752@redhat.com> (raw)
In-Reply-To: <alpine.BSF.2.22.395.2003311417190.73689@zero.eik.bme.hu>

On Tue, Mar 31, 2020 at 02:33:46PM +0200, BALATON Zoltan wrote:
> > We will have to ask developers to change habits anyway when we switch to
> > Meson.  I agree with Daniel's recommendation to delay changes requiring
> > habit-changes until then.  However, telling people to stay clear of the
> > unloved and brittle in-tree build is simply good advice we should not
> > withhold.
> 
> Can someone please explain why is it brittle and cannot be supported? It has
> worked well so far apart from some breakage due to being untested which is
> also not a techincal necessity just a decision by some maintiners to not
> test it. Adding a CI job to keep it working would also not be difficult or
> much complexity.

Writing make rules to correctly handle both src-dir and build-dir scenarios
is a non-negligible maint burden. If you look back through QEMU's history
we have a steady stream of patches which have broken one or the other
build scenarios.

Developers will often not test both scenarios, just the one they prefer
to use. This results in a maint burden on the subsystem maintainers who
merge patches and then find they break & have to back them out. Sometimes
even the subsystem maintainer gets it wrong and burden falls on Peter to
find & reject it.

Even if we have CI to test both, it is still a burden on developers to
debug failures reported by the CI and figure out what needs fixing. With
the number of builds we do & the time for a single CI cycle it gets very
time consuming. I've personally wasted many many hours debugging src-dir
vs build-dir problems in QEMU's makefiles - probably more than an entire
day was lost when I did the patches to split the trace.h header file.

This all serves to divert time away from useful work on QEMU. If there
was some critically important functional thing that src-dir builds offer
that can't be achieved by build-dir builds, then the extra maint work
could be justified. I don't think that's the case though.

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	other threads:[~2020-03-31 12:51 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-21 20:50 deprecation of in-tree builds Peter Maydell
2020-03-21 22:50 ` BALATON Zoltan
2020-03-23 13:32   ` Stefan Hajnoczi
2020-03-24 13:54     ` Eric Blake
2020-08-18 19:14     ` Peter Maydell
2020-08-20 10:54       ` Kevin Wolf
2020-08-20 11:14         ` Michael Tokarev
2020-08-20 11:56         ` Paolo Bonzini
2020-08-20 12:00           ` Peter Maydell
2020-08-20 13:30           ` Kevin Wolf
2020-08-20 14:10             ` Peter Maydell
2020-08-20 15:50             ` Paolo Bonzini
2020-08-20 16:14               ` Kevin Wolf
2020-08-20 17:39                 ` Paolo Bonzini
2020-08-21  9:55                   ` Gerd Hoffmann
2020-08-20 16:05       ` Daniel P. Berrangé
     [not found] ` <CAL1e-=gKB0qRxGntXrU0im2gjMh1tq_SLGTm+HsmgBRGXQ9+Bg@mail.gmail.com>
2020-03-22 17:20   ` Peter Maydell
2020-03-22 19:51     ` Aleksandar Markovic
2020-03-22 20:14       ` Peter Maydell
2020-03-22 20:45         ` Aleksandar Markovic
2020-03-22 20:46         ` BALATON Zoltan
2020-03-22 21:15           ` Peter Maydell
2020-03-23  0:35             ` BALATON Zoltan
2020-03-23 10:20         ` Daniel P. Berrangé
2020-03-30 13:26 ` Markus Armbruster
2020-03-30 13:31   ` Peter Maydell
2020-03-30 13:42     ` Daniel P. Berrangé
2020-03-30 14:37       ` Kevin Wolf
2020-03-30 17:29         ` Michal Suchánek
2020-03-30 17:36           ` Daniel P. Berrangé
2020-03-30 20:15           ` BALATON Zoltan
2020-03-31  7:48         ` Paolo Bonzini
2020-03-31  9:20           ` Liviu Ionescu
2020-03-31 10:19             ` Peter Maydell
2020-03-31 11:46               ` Liviu Ionescu
2020-03-31 12:07                 ` Kevin Wolf
2020-03-31 15:23                   ` Liviu Ionescu
2020-03-31 12:02           ` Kevin Wolf
2020-03-31 12:05             ` Peter Maydell
2020-03-31 12:24               ` Kevin Wolf
2020-03-31 12:32                 ` Peter Maydell
2020-03-31 15:08             ` Eric Blake
2020-03-31 15:20               ` BALATON Zoltan
2020-03-31 15:44                 ` Kevin Wolf
2020-03-31 12:54           ` BALATON Zoltan
2020-03-30 16:25     ` Aleksandar Markovic
2020-03-31  7:15     ` Markus Armbruster
2020-03-31 12:33       ` BALATON Zoltan
2020-03-31 12:50         ` Daniel P. Berrangé [this message]
2020-03-31 15:04           ` BALATON Zoltan
2020-03-31 15:23             ` Daniel P. Berrangé
2020-03-31 15:55               ` BALATON Zoltan
2020-03-31 10:38 ` Daniel P. Berrangé

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=20200331125030.GG353752@redhat.com \
    --to=berrange@redhat.com \
    --cc=armbru@redhat.com \
    --cc=balaton@eik.bme.hu \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.