Re: [PATCH] configure: add support for psuedo-"in source tree" builds

[Kevin Wolf <kwolf@redhat.com>]

Am 20.08.2020 um 19:42 hat Eric Blake geschrieben:
> On 8/20/20 11:55 AM, Daniel P. Berrangé wrote:
> > Meson requires the build dir to be separate from the source tree. Many
> > people are used to just running "./configure && make" though and the
> > meson conversion breaks that.
> > 
> > This introduces some backcompat support to make it appear as if an
> > "in source tree" build is being done, but with the the results in the
> > "build/" directory. This allows "./configure && make" to work as it
> > did historically, albeit with the output binaries staying under build/.
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> 
> In addition to reviews you already have,
> 
> 
> > I've not tested it beyond that. Note it blows away the "build/"
> > dir each time ./configure is run so it is pristine each time.
> 
> I definitely like the idea of only blowing away what we created - but if we
> created build, then recreating it for each new configure run is nice.

I think I actually wouldn't automatically remove anything on configure.
It can be surprising behaviour for configure to delete directories, and
the old setup didn't do an automatic "make clean" either. By having a
separate build directory, manually emptying as needed has already become
easier.

> > We could optionally symlink binaries from build/ into $PWD
> > if poeople think that is important, eg by changing GNUmakefile
> > to have:
> > 
> > recurse: all
> > 	for bin in `find build -maxdepth 1 -type f -executable | grep -v -E '(ninjatool|config.status)'`; \
> 
> Using -maxdepth gets rid of the need to pre-create empty directories for
> nested binaries, but also loses out on binaries such as
> x86_64-softmmu/qemu-system-x86_64.  Oh, it looks like meson creates
> qemu-system-x86_64 as a binary in the top level, then a symlink in its old
> location.  Populating symlinks to ALL old locations is thus trickier than
> what you are proposing here, so it is fine to save that for a followup patch
> (let's get the bare minimum in first, so that at least ./configure && make
> works, before we worry about back-compat symlinks).

Having the system emulator symlinks in the top level would be a change,
but even more convenient than the original places. I'd vote for adding
the auto-symlinking at least for the tools; if the top-level symlinks
for system emulators get also symlinked by this, that's fine, too.

I was actually surprised that Dan reports "make check" from the source
tree to be working without the symlinks. Some code must be cleverer than
I thought!

Kevin