[Top][All Lists]

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

Re: deprecation of in-tree builds

From: BALATON Zoltan
Subject: Re: deprecation of in-tree builds
Date: Mon, 23 Mar 2020 01:35:46 +0100 (CET)
User-agent: Alpine 2.22 (BSF 395 2020-01-19)

On Sun, 22 Mar 2020, Peter Maydell wrote:
On Sun, 22 Mar 2020 at 20:46, BALATON Zoltan <address@hidden> 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

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

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.


reply via email to

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