All of lore.kernel.org
 help / color / mirror / Atom feed
From: BALATON Zoltan <balaton@eik.bme.hu>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Aleksandar Markovic <aleksandar.m.mail@gmail.com>
Subject: Re: deprecation of in-tree builds
Date: Mon, 23 Mar 2020 01:35:46 +0100 (CET)	[thread overview]
Message-ID: <alpine.BSF.2.22.395.2003230113170.33355@zero.eik.bme.hu> (raw)
In-Reply-To: <CAFEAcA_GR__MVOU=LVUuQwnwM23DYxbp4Gi00mKJCoLrxL9j0g@mail.gmail.com>

On Sun, 22 Mar 2020, Peter Maydell wrote:
> On Sun, 22 Mar 2020 at 20:46, BALATON Zoltan <balaton@eik.bme.hu> wrote:
>> On Sun, 22 Mar 2020, Peter Maydell wrote:
>>> Before you told me about the gprof issue, the *only* thing
>>
>> Was that gprof or gcov?
>
> Sorry, gcov; I always get those two mixed up in my head.
>
>> Plus potentially any scripts people might use to build stuff and distro
>> packagers that might use in-tree build. They would suddently find their
>> previously working scripts are now broken and they need to adapt.
>
> It is to avoid the "suddenly" part that we announce in advance
> that features are going away :-)  More generally, distro packagers

People usually don't read docs so they'll find out "suddenly" anyway...

> must adapt for any new QEMU release -- new features appear that
> they may need to update their dependency lists to handle, old
> features are sometimes removed and the corresponding configure
> --enable-foo options stop working, existing features need new
> dependencies.

It's true they'll occasionally have to adapt and probably most packagers 
already use out-of-tree builds but if there's something that can make 
their life easier without putting too much burden on QEMU I think it's a 
good thing to make it convenient for people compiling QEMU.

> If somebody wants to write patches to cause 'configure' to create
> a new build tree that's OK I guess (though I'd be dubious because
> I think that hidden magic like that is overall often going
> to confuse people, and it's still extra machinery in the
> makefile and the configure script). But I don't really see
> much point in maintaining two different mechanisms which add
> complication and where one of them is just not overall as useful
> as the other.

A convenience Makefile in top level to call make -C builddir and maybe a 
few lines in configure to create it does not seem to be too much extra 
machinery but I don't know the build system that well. Also it does not 
have to be hidden, it can print a message to user to tell it created a 
build dir and that the build results are found there. It's probably less 
confusing to people who never used out-of-tree builds before and relieves 
them from having to learn something new which a lot of people like to 
avoid if possible.

> I fairly often see posts from people on eg stackoverflow
> who are trying to compile and modify QEMU, and they're
> usually using in-tree build and I usually mention in a
> PS to answering their question that they'd really be
> better off with an out-of-tree build. I think we should
> stop making it easy to default to a setup that we don't
> recommend.

I think this proves my point that a lot of people expect this to work and 
the answer should not be to annoy them and force them to change their ways 
but to support it in some way. If this is a problem with the make system 
then auto-creating build dir could avoid this problem without imposing 
things on people so if it's not too much effort it's probably worth doing.

Regards,
BALATON Zoltan


  reply	other threads:[~2020-03-23  0:36 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 [this message]
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é
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=alpine.BSF.2.22.395.2003230113170.33355@zero.eik.bme.hu \
    --to=balaton@eik.bme.hu \
    --cc=aleksandar.m.mail@gmail.com \
    --cc=aleksandar.qemu.devel@gmail.com \
    --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.