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ÃÆé <berra...@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
