Re: deprecation of in-tree builds

[Eric Blake <eblake@redhat.com>]

On 3/31/20 7:02 AM, Kevin Wolf wrote:
> Am 31.03.2020 um 09:48 hat Paolo Bonzini geschrieben:
>> On 30/03/20 16:37, Kevin Wolf wrote:
>>> If manually dealing with separate build directories is inconvenient
>>> today, 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?  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.
> 
> Mainly because it allows me to start everything (most importantly: my
> editor, git and make) from the same directory.
> 
> I guess the automatic directory creation is the less important part
> compared to a Makefile in the source tree that calls the Makefile in the
> build directory, because creation the directory is a one-time thing, but
> I call make all the time.

If we make in-tree ./configure create a GNUmakefile shim that 
auto-forwards to build/, it would also be possible to create symlinks to 
the various targets that will live in build.  I recently switched my 
qemu playground to use VPATH builds, but with symlinks such as qemu-img 
-> build/qemu-img, I can still use my muscle memory of an in-tree build 
for normal development.

> 
> Creating it automatically is nice especially for those who build QEMU
> for the first time and expect that the ./configure; make; make install
> sequence they are used to just works.
> 
> Prefixing build/ when using the binaries is a change, too, but I guess
> tab completion means that it's not much worse than prefixing ./

With symlinks, it is possible to give much more than 'make' the illusion 
of working in-tree.  It then boils down to a question of how many 
symlinks are worth creating.

> 
>> I can see why it's more convenient for packaging, as they just invoke
>> "make" and "make install", but as far as developers are concerned it
>> seems to add complexity for little or no gain.
> 
> I often use the same terminal for building/testing and git, or sometimes
> even a second editor for source code.
> 
> Kevin
> 
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org