16:44 Pet, 03.04.2020. Eric Blake <ebl...@redhat.com> је написао/ла: > > On 4/3/20 9:02 AM, Eric Blake wrote: > > On 4/3/20 8:53 AM, Daniel P. Berrangé wrote: > >> Running configure directly from the source directory is a build > >> configuration that will go away in future. It is also not currently > >> covered by any automated testing. Display a deprecation warning if > >> the user attempts to use an in-srcdir build setup, so that they are > >> aware that they're building QEMU in an undesirable manner. > >> > >> Reviewed-by: Eric Blake <ebl...@redhat.com> > >> Reviewed-by: Markus Armbruster <arm...@redhat.com> > >> Reviewed-by: Philippe Mathieu-Daudé <phi...@redhat.com> > >> Tested-by: Philippe Mathieu-Daudé <phi...@redhat.com> > >> Signed-off-by: Daniel P. Berrangé <berra...@redhat.com> > >> --- > >> > >> Changed in v4: > >> - Adopted Eric's suggested wording > > > >> +if test "$in_srcdir" = "yes"; then > >> + echo > >> + echo "WARNING: SUPPORT FOR BUILDING IN THE SOURCE DIR IS DEPRECATED" > >> + echo > >> + echo "Support for running the 'configure' script directly from the" > >> + echo "source directory is deprecated. In-tree builds are not > >> covered" > >> + echo "by automated testing and thus may not correctly build QEMU." > >> + echo "Users are recommended to use a separate build directory:" > >> + echo > >> + echo " $ mkdir build" > >> + echo " $ cd build" > >> + echo " $ ../configure" > >> + echo " $ make" > > > > Late question, but: > > > > Since this is just a warning, we still manage to complete the > > ./configure run, including whatever generated files it leaves in-tree. > > Is there any additional step we need to recommend prior to 'mkdir build' > > that will clean up the in-tree artifacts, so that the user then > > attempting the VPATH build won't still have a broken build due to the > > leftovers from the in-tree attempt? 'make distclean', perhaps? > > > > /me starts testing; I'll reply back once it finishes... > > tl;dr: 'make distclean' isn't perfect (it still leaves 2 directories > behind), but does clean up a lot of directories and .mak files, and IS > necessary before you can build in the subdirectory; but at least make > warns you. Still, I'd prefer adding that step in the warning, rather > than getting an error several steps later. > > On a fresh git checkout: > > $ ./configure > ... > $ git clean -dfxn > Would remove aarch64-linux-user/ > Would remove aarch64-softmmu/ > Would remove aarch64_be-linux-user/ > Would remove alpha-linux-user/ > Would remove alpha-softmmu/ > Would remove arm-linux-user/ > Would remove arm-softmmu/ > Would remove armeb-linux-user/ > Would remove config-all-disas.mak > Would remove config-host.mak > Would remove config.log > Would remove config.status > Would remove cris-linux-user/ > Would remove cris-softmmu/ > Would remove docs/sphinx/__pycache__/ > Would remove hppa-linux-user/ > Would remove hppa-softmmu/ > Would remove i386-linux-user/ > Would remove i386-softmmu/ > Would remove linux-headers/asm > Would remove lm32-softmmu/ > Would remove m68k-linux-user/ > Would remove m68k-softmmu/ > Would remove microblaze-linux-user/ > Would remove microblaze-softmmu/ > Would remove microblazeel-linux-user/ > Would remove microblazeel-softmmu/ > Would remove mips-linux-user/ > Would remove mips-softmmu/ > Would remove mips64-linux-user/ > Would remove mips64-softmmu/ > Would remove mips64el-linux-user/ > Would remove mips64el-softmmu/ > Would remove mipsel-linux-user/ > Would remove mipsel-softmmu/ > Would remove mipsn32-linux-user/ > Would remove mipsn32el-linux-user/ > Would remove moxie-softmmu/ > Would remove nios2-linux-user/ > Would remove nios2-softmmu/ > Would remove or1k-linux-user/ > Would remove or1k-softmmu/ > Would remove ppc-linux-user/ > Would remove ppc-softmmu/ > Would remove ppc64-linux-user/ > Would remove ppc64-softmmu/ > Would remove ppc64abi32-linux-user/ > Would remove ppc64le-linux-user/ > Would remove riscv32-linux-user/ > Would remove riscv32-softmmu/ > Would remove riscv64-linux-user/ > Would remove riscv64-softmmu/ > Would remove rx-softmmu/ > Would remove s390x-linux-user/ > Would remove s390x-softmmu/ > Would remove sh4-linux-user/ > Would remove sh4-softmmu/ > Would remove sh4eb-linux-user/ > Would remove sh4eb-softmmu/ > Would remove sparc-linux-user/ > Would remove sparc-softmmu/ > Would remove sparc32plus-linux-user/ > Would remove sparc64-linux-user/ > Would remove sparc64-softmmu/ > Would remove tests/qemu-iotests/common.env > Would remove tests/qgraph/ > Would remove tests/tcg/config-aarch64-linux-user.mak > Would remove tests/tcg/config-aarch64-softmmu.mak > Would remove tests/tcg/config-aarch64_be-linux-user.mak > Would remove tests/tcg/config-alpha-linux-user.mak > Would remove tests/tcg/config-alpha-softmmu.mak > Would remove tests/tcg/config-arm-linux-user.mak > Would remove tests/tcg/config-arm-softmmu.mak > Would remove tests/tcg/config-armeb-linux-user.mak > Would remove tests/tcg/config-cris-linux-user.mak > Would remove tests/tcg/config-cris-softmmu.mak > Would remove tests/tcg/config-hppa-linux-user.mak > Would remove tests/tcg/config-hppa-softmmu.mak > Would remove tests/tcg/config-i386-linux-user.mak > Would remove tests/tcg/config-i386-softmmu.mak > Would remove tests/tcg/config-lm32-softmmu.mak > Would remove tests/tcg/config-m68k-linux-user.mak > Would remove tests/tcg/config-m68k-softmmu.mak > Would remove tests/tcg/config-mips-linux-user.mak > Would remove tests/tcg/config-mips-softmmu.mak > Would remove tests/tcg/config-mips64-linux-user.mak > Would remove tests/tcg/config-mips64-softmmu.mak > Would remove tests/tcg/config-mips64el-linux-user.mak > Would remove tests/tcg/config-mips64el-softmmu.mak > Would remove tests/tcg/config-mipsel-linux-user.mak > Would remove tests/tcg/config-mipsel-softmmu.mak > Would remove tests/tcg/config-mipsn32-linux-user.mak > Would remove tests/tcg/config-mipsn32el-linux-user.mak > Would remove tests/tcg/config-ppc-linux-user.mak > Would remove tests/tcg/config-ppc-softmmu.mak > Would remove tests/tcg/config-ppc64-linux-user.mak > Would remove tests/tcg/config-ppc64-softmmu.mak > Would remove tests/tcg/config-ppc64abi32-linux-user.mak > Would remove tests/tcg/config-ppc64le-linux-user.mak > Would remove tests/tcg/config-riscv64-linux-user.mak > Would remove tests/tcg/config-riscv64-softmmu.mak > Would remove tests/tcg/config-s390x-linux-user.mak > Would remove tests/tcg/config-s390x-softmmu.mak > Would remove tests/tcg/config-sh4-linux-user.mak > Would remove tests/tcg/config-sh4-softmmu.mak > Would remove tests/tcg/config-sh4eb-linux-user.mak > Would remove tests/tcg/config-sh4eb-softmmu.mak > Would remove tests/tcg/config-sparc64-linux-user.mak > Would remove tests/tcg/config-sparc64-softmmu.mak > Would remove tests/tcg/config-x86_64-linux-user.mak > Would remove tests/tcg/config-x86_64-softmmu.mak > Would remove tests/tcg/config-xtensa-linux-user.mak > Would remove tests/tcg/config-xtensa-softmmu.mak > Would remove tests/tcg/config-xtensaeb-linux-user.mak > Would remove tests/tcg/config-xtensaeb-softmmu.mak > Would remove tilegx-linux-user/ > Would remove tricore-softmmu/ > Would remove unicore32-softmmu/ > Would remove x86_64-linux-user/ > Would remove x86_64-softmmu/ > Would remove xtensa-linux-user/ > Would remove xtensa-softmmu/ > Would remove xtensaeb-linux-user/ > Would remove xtensaeb-softmmu/ > $ make distclean > ... > $ git clean -dfxn > Would remove docs/sphinx/__pycache__/ > Would remove tests/qgraph/ > $ ./configure > ... > $ mkdir build > $ cd build > $ ../configure > $ make > Makefile:58: *** This is an out of tree build but your source tree > (/home/eblake/qemu-tmp) seems to have been used for an in-tree build. > You can fix this by running "make distclean && rm -rf *-linux-user > *-softmmu" in your source tree. Stop. > $ cd .. > $ make distclean && rm -rf *-linux-user *-softmmu > $ cd build > $ make > ... >
But, Eric, while, to some extent I understand your motivation and the idea, there are still features working in in-tree builds only (some coccinele scenarios, and some gcov-related scenarios - and perhaps others that nobody seems to care to try to find out at all), and not in out-of tree builds. And, now, if I understand well your proposal, and supposing that I use gcov in-tree build (since I have to), this will stop me from doing out-of-tree builds in this QEMU directory, since my in-tree gcov build will be destroyed. OK, I can use two separate directories as a workaround, but what bothers me is that such proposal makes my workflow more complicated, driven by almost obsesive desire to eradicate in-tree builds, instead on focusing on making sure that out-of-build tree supports absolutely all and the same functionality as in-tree builds, which is, I repeat, not the case right now. Further, now speaking to Daniel, I don't have anything from the fact that all CI tests are done with out-of-tree builds, if the feature I use works only in in-tree builds. The whole message has some vieled disregarding tone for people forced to use in-tree builds, and I see it as very close to "pulling the rug under people" for such cases, and Peter said this should not be happening. Of course, many peaple are so wonderful when it comes to "exterminating" in-tree builds, but when it comes to efforts to make sure everything works in out-of-tree builds as in in-tree builds, suddenly everybody disappears, don't have bandwith, don't care for something that doesn't affect them, seem not to want to even think about such cases, etc.etc. Disappointing! Sincerely, Aleksandar > > -- > Eric Blake, Principal Software Engineer > Red Hat, Inc. +1-919-301-3226 > Virtualization: qemu.org | libvirt.org > >
