Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
On Sun, Apr 05, 2020 at 03:38:55PM +0100, Peter Maydell wrote: > On Fri, 3 Apr 2020 at 14:53, 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 > > Reviewed-by: Markus Armbruster > > Reviewed-by: Philippe Mathieu-Daudé > > Tested-by: Philippe Mathieu-Daudé > > Signed-off-by: Daniel P. Berrangé > > --- > > > +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 -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
11:14 Sub, 04.04.2020. Peter Maydell је написао/ла: > > On Fri, 3 Apr 2020 at 23:35, Aleksandar Markovic > 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
Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
16:39 Ned, 05.04.2020. Peter Maydell је написао/ла: > > On Fri, 3 Apr 2020 at 14:53, 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 > > Reviewed-by: Markus Armbruster > > Reviewed-by: Philippe Mathieu-Daudé > > Tested-by: Philippe Mathieu-Daudé > > Signed-off-by: Daniel P. Berrangé > > --- > > > +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 > thanks > -- PMM >
Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
On Fri, 3 Apr 2020 at 14:53, 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 > Reviewed-by: Markus Armbruster > Reviewed-by: Philippe Mathieu-Daudé > Tested-by: Philippe Mathieu-Daudé > Signed-off-by: Daniel P. Berrangé > --- > +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
Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
On Fri, 3 Apr 2020 at 23:35, Aleksandar Markovic 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
Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
16:44 Pet, 03.04.2020. Eric Blake је написао/ла: > > 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 > >> Reviewed-by: Markus Armbruster > >> Reviewed-by: Philippe Mathieu-Daudé > >> Tested-by: Philippe Mathieu-Daudé > >> Signed-off-by: Daniel P. Berrangé > >> --- > >> > >> 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
Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
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 Reviewed-by: Markus Armbruster Reviewed-by: Philippe Mathieu-Daudé Tested-by: Philippe Mathieu-Daudé Signed-off-by: Daniel P. Berrangé --- 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
Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
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 Reviewed-by: Markus Armbruster Reviewed-by: Philippe Mathieu-Daudé Tested-by: Philippe Mathieu-Daudé Signed-off-by: Daniel P. Berrangé --- 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
Re: [PATCH v4 for-5.0] configure: warn if not using a separate build directory
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 Reviewed-by: Markus Armbruster Reviewed-by: Philippe Mathieu-Daudé Tested-by: Philippe Mathieu-Daudé Signed-off-by: Daniel P. Berrangé --- 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... -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
