| Message ID | 20200403135306.665493-1-berrange@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v4,for-5.0] configure: warn if not using a separate build directory | expand |
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 <eblake@redhat.com> > Reviewed-by: Markus Armbruster <armbru@redhat.com> > Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> > Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> > Signed-off-by: Daniel P. Berrangé <berrange@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...
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 <eblake@redhat.com> >> Reviewed-by: Markus Armbruster <armbru@redhat.com> >> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> >> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> >> Signed-off-by: Daniel P. Berrangé <berrange@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 ...
On Fri, 3 Apr 2020, 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 <eblake@redhat.com> >> Reviewed-by: Markus Armbruster <armbru@redhat.com> >> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> >> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> >> Signed-off-by: Daniel P. Berrangé <berrange@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... You proabably also need make distclean before going to use build dir. Since in-tree build continues to work as before and hopefully even after it won't some convenience functions will take care of it without the user having to do it by hand I wonder if such a long warning is really needed in configure now. Other than uselessly annoying users, what does this patch achieve? The recommended way to build may change again when build system is replaced and I won't change my usual way until it works and going to just ignore this warning and I guess others who like in-tree builds will do the same. But I've already said that so probably won't mention it again. Regards, BALATON Zoltan
16:44 Pet, 03.04.2020. Eric Blake <eblake@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 <eblake@redhat.com> > >> Reviewed-by: Markus Armbruster <armbru@redhat.com> > >> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> > >> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> > >> Signed-off-by: Daniel P. Berrangé <berrange@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 > >
On Fri, 3 Apr 2020 at 23:35, Aleksandar Markovic
<aleksandar.qemu.devel@gmail.com> wrote:
> 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.
To repeat from the last thread: we are *not going* to remove in-tree
builds before we fix whatever we need to to allow people to
use out-of-tree for whatever they are currently doing with in-tree
builds. The reason for putting in deprecation warnings etc now
is timescales: releases are every four months or so, so if we
want to warn users about something we need to put in that warning
well in advance. Bug fixes on the other hand can go into the tree
very quickly, so we can without any problems have a timeline that
goes deprecation-notice --- fix bugs with out-of-tree builds -- remove
or convert in-tree builds to automatically out-of-tree.
Plus the only way we find out about problems we're going to need
to fix is if we tell people "in-tree is going away" and they then tell
us "er, XYZ doesn't seem to work out-of-tree".
The reason people are currently focusing on the warning bit
is that we have about one week to do that if we want to get
it into this release. After that we have months to investigate
and fix the problems with out-of-tree builds.
Can you provide repro instructions for your gcov issue?
What is the "coccinelle scenario" you mention?
thanks
-- PMM
On Fri, 3 Apr 2020 at 14:53, Daniel P. Berrangé <berrange@redhat.com> 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 <eblake@redhat.com> > Reviewed-by: Markus Armbruster <armbru@redhat.com> > Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> > Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > --- > +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" > + echo > +fi So here's my stab at some text here; I'm aiming at nudging users towards out-of-tree builds if they were simply not thinking about it, but not actively marking them as 'deprecated', since it sounded to me like we were planning to keep at least the basic 'configure+make+make install' sequence of commands working. echo "NOTE: we recommend against building in the source directory" echo echo "You've run the 'configure' script directly from the source" echo "directory. This will work, but we recommend using a separate" echo "build directory, especially if you plan to work with the QEMU" echo "sources rather than just building it once. You can switch to" echo "a separate build directory like this:" [instructions go here] thanks -- PMM
16:39 Ned, 05.04.2020. Peter Maydell <peter.maydell@linaro.org> је написао/ла: > > On Fri, 3 Apr 2020 at 14:53, Daniel P. Berrangé <berrange@redhat.com> 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 <eblake@redhat.com> > > Reviewed-by: Markus Armbruster <armbru@redhat.com> > > Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> > > Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > > --- > > > +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" > > + echo > > +fi > > So here's my stab at some text here; I'm aiming at nudging users > towards out-of-tree builds if they were simply not thinking about > it, but not actively marking them as 'deprecated', since it sounded > to me like we were planning to keep at least the basic > 'configure+make+make install' sequence of commands working. > > echo "NOTE: we recommend against building in the source directory" > echo > echo "You've run the 'configure' script directly from the source" > echo "directory. This will work, but we recommend using a separate" > echo "build directory, especially if you plan to work with the QEMU" > echo "sources rather than just building it once. You can switch to" > echo "a separate build directory like this:" > [instructions go here] > Peter's version is far more superior to Daniel's. I'd better not discuss the reasons, not wanting to waste my time and other's time. For Peter's version: Reviewed-by: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com> > thanks > -- PMM >
11:14 Sub, 04.04.2020. Peter Maydell <peter.maydell@linaro.org> је написао/ла: > > On Fri, 3 Apr 2020 at 23:35, Aleksandar Markovic > <aleksandar.qemu.devel@gmail.com> wrote: > > 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. > > To repeat from the last thread: we are *not going* to remove in-tree > builds before we fix whatever we need to to allow people to > use out-of-tree for whatever they are currently doing with in-tree > builds. I am with you, Peter, and I truly appreciate your repeating that for the second time. But, what made me upset, obviously not everybody is reading your statements. If you really carefully read responses to the original thread started by you and also subsequent threads, you'll see that a number of suggestions either cripple or outrightly effectively remove in-tree builds! And all that not in 4 months, not in 8 months, but now, in the same patch that was discussed (maybe the authors meant "later", but certainly did not write that). (on closer examination, perhaps Eric's proposal does not belong to this catehory, so my apologies to Eric) > The reason for putting in deprecation warnings etc now > is timescales: releases are every four months or so, so if we > want to warn users about something we need to put in that warning > well in advance. Bug fixes on the other hand can go into the tree > very quickly, so we can without any problems have a timeline that > goes deprecation-notice --- fix bugs with out-of-tree builds -- remove > or convert in-tree builds to automatically out-of-tree. > > Plus the only way we find out about problems we're going to need > to fix is if we tell people "in-tree is going away" and they then tell > us "er, XYZ doesn't seem to work out-of-tree". > Understood. > The reason people are currently focusing on the warning bit > is that we have about one week to do that if we want to get > it into this release. After that we have months to investigate > and fix the problems with out-of-tree builds. > > Can you provide repro instructions for your gcov issue? > I unfortunately can't, because I am working from home, and having difficulties accessing my dev system with said behavior, that I left at the company. If and when these difficulties disappear, I will gladly and certainly send a bug report. > What is the "coccinelle scenario" you mention? > I meant to say the scenario you mention in your original thread on the same topic from the other day, and perhaps you said "Coverity", and not "coccinele" - and I mixed up the two. So, in other words, nothing new, I was just echoing what you said before, the other day, in a response to one of my messages. Regards, Aleksandar > thanks > -- PMM
On Sun, Apr 05, 2020 at 03:38:55PM +0100, Peter Maydell wrote: > On Fri, 3 Apr 2020 at 14:53, Daniel P. Berrangé <berrange@redhat.com> 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 <eblake@redhat.com> > > Reviewed-by: Markus Armbruster <armbru@redhat.com> > > Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> > > Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> > > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> > > --- > > > +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" > > + echo > > +fi > > So here's my stab at some text here; I'm aiming at nudging users > towards out-of-tree builds if they were simply not thinking about > it, but not actively marking them as 'deprecated', since it sounded > to me like we were planning to keep at least the basic > 'configure+make+make install' sequence of commands working. > > echo "NOTE: we recommend against building in the source directory" > echo > echo "You've run the 'configure' script directly from the source" > echo "directory. This will work, but we recommend using a separate" > echo "build directory, especially if you plan to work with the QEMU" > echo "sources rather than just building it once. You can switch to" > echo "a separate build directory like this:" I'm fine with that text too. I'll submit another version of the patch with that incorporated Regards, Daniel
diff --git a/configure b/configure index 22870f3867..d275c36c85 100755 --- a/configure +++ b/configure @@ -285,6 +285,16 @@ then error_exit "main directory cannot contain spaces nor colons" fi +canon_build_path=$(realpath -- "$PWD") +canon_source_path=$(realpath -- "$source_path") + +in_srcdir=no +if [ "$canon_build_path" = "$canon_source_path" ] +then + in_srcdir=yes +fi + + # default parameters cpu="" iasl="iasl" @@ -6751,6 +6761,22 @@ if test "$supported_os" = "no"; then echo "us upstream at qemu-devel@nongnu.org." fi +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" + echo +fi + config_host_mak="config-host.mak" echo "# Automatically generated by configure - do not modify" >config-all-disas.mak