Re: deprecation of in-tree builds

[Liviu Ionescu <ilg@livius.net>]

> On 31 Mar 2020, at 10:48, Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> On 30/03/20 16:37, Kevin Wolf wrote:
>> If manually dealing with separate build directories is inconvenient
>> today,

It may be for some, but it isn't for all, perhaps we should not generalise and get the wrong conclusions.

In the xPack Build Box (a set of Docker images) that I use for the binary xPack builds, I probably have some tens of libraries and tools, and most of them use separate build folders, no problem with this.

With these docker images I build, on the same 64-bit linux machine, multi-platform QEMU binaries (and other complicated things like toolchains), and for them I use separate build folders for each target platform (win32, win64, linux32, linux64) and a common source folder.

>> it will still be inconvenient with Meson, so this would mean
>> introducing the automatic directly creation together with the other
>> changes to enable Meson. Which is fine by me, as long as it is really
>> done when the external directory becomes mandatory, so that people won't
>> have to switch back and forth between directories.
> 
> Serious question: why is automatic directly creation more convenient for
> developers?

For my use case it isn't, automatic creation will break my folder structure and I'll not be able to use the common source folder and multiple target build folders structure that I use now.

>  Even if "./configure" generates a "build" directory for
> you, you would still have to invoke the QEMU binary as
> "build/x86_64-softmmu/qemu-system-x86_64".  That is less convenient than
> doing "mkdir build" in the first place.

I agree, if 'build' can be anywhere, not necessarily inside the source tree.

I just tested, and meson creates the build folder where it is instructed to, it can be inside or outside the source folder, so I think that the QEMU build procedure should preserve his freedom, and not enforced the use of a specific folder, otherwise performing multi-platform builds will be more complicated than necessary.


Regards,

Liviu