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

[Kevin Wolf]

Am 21.08.2020 um 12:14 hat Daniel P. Berrangé geschrieben:
> On Fri, Aug 21, 2020 at 11:58:21AM +0200, Kevin Wolf wrote:
> > 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.
> 
> The issue is that previously you could do
> 
>   ./configure
>   make
>   ./configure
>   make
> 
> This isn't possible with the new system because meson will refuse
> to use the "build/" directory if it already contains a previous
> configured build.

Oh. So now you always have to create a new build directory if you want
to change configure options?

> Doing "rm -rf build" in configure lets the above sequence work.
> 
> I can remove the "rm -rf biuld" in configure if we are happy
> to require
> 
>   ./configure
>   make
>   make distclean
>   ./configure
>   make
> 
> because the "GNUmakefile" wires up "distclean" to purge the
> build/ directory.

Hm, I see. Then maybe better keep the 'rm'.

> > > > 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!
> 
> That's because "make check" is not actually running from the source
> tree. When you run "make check" in the source tree, what's acutally
> happening is
> 
>   cd build
>   make check
> 
> so it is actually running from build-dir context.

Yup, I wasn't aware that it would do this.

Kevin