Message ID | 20200930195850.278104-1-pbonzini@redhat.com |
---|---|
Headers | show |
Series | Misc QEMU patches for 2020-09-24 | expand |
On Wed, 30 Sep 2020 at 21:04, Paolo Bonzini <pbonzini@redhat.com> wrote: > > The following changes since commit cbba3dc6ea3fc9aa66e9f9eb41051536e3ad7cd0: > > Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging (2020-09-30 11:40:38 +0100) > > are available in the Git repository at: > > https://gitlab.com/bonzini/qemu.git tags/for-upstream > > for you to fetch changes up to 37aeb7a28ddbf52dd25dd53ae1b8391bc2287858: > > hw/net/can: Correct Kconfig dependencies (2020-09-30 19:11:37 +0200) > > ---------------------------------------------------------------- > * SCSI fix (Dmitry, Li Feng, Li Qiang) > * memory API fixes (Eduardo) > * removal of deprecated '-numa node', 'cpu-add', '-smp' (Igor) > * ACPI fix for VMBus (Jon) > * relocatable install (myself) > * always remove docker containers (myself) > * serial cleanups (Philippe) > * vmware cpuid leaf for tsc and apic frequency (Sunil) > * KVM_FEATURE_ASYNC_PF_INT support (Vitaly) > * i386 XSAVE bugfix (Xiaoyao) > * QOM developer documentation in docs/devel (Eduardo) > * new checkpatch tests (Dov) > * x86_64 syscall fix (Douglas) > * interrupt-based APF fix (Vitaly) > * always create kvmclock (Vitaly) > * fix bios-tables-test (Eduardo) > * KVM PV features cleanup (myself) > * CAN FD (Pavel) > > meson: > * fixes (Marc-André, Max, Stefan, Alexander, myself) > * moved libmpathpersist, cocoa, malloc tests (myself) > * support for 0.56 introspected test dependencies (myself) > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/5.2 for any user-visible changes. -- PMM
On Thu, Oct 1, 2020 at 10:36 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > On Wed, 30 Sep 2020 at 21:04, Paolo Bonzini <pbonzini@redhat.com> wrote: > > > > The following changes since commit cbba3dc6ea3fc9aa66e9f9eb41051536e3ad7cd0: > > > > Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging (2020-09-30 11:40:38 +0100) > > > > are available in the Git repository at: > > > > https://gitlab.com/bonzini/qemu.git tags/for-upstream > > > > for you to fetch changes up to 37aeb7a28ddbf52dd25dd53ae1b8391bc2287858: > > > > hw/net/can: Correct Kconfig dependencies (2020-09-30 19:11:37 +0200) > > > > ---------------------------------------------------------------- > > * SCSI fix (Dmitry, Li Feng, Li Qiang) > > * memory API fixes (Eduardo) > > * removal of deprecated '-numa node', 'cpu-add', '-smp' (Igor) > > * ACPI fix for VMBus (Jon) > > * relocatable install (myself) > > * always remove docker containers (myself) > > * serial cleanups (Philippe) > > * vmware cpuid leaf for tsc and apic frequency (Sunil) > > * KVM_FEATURE_ASYNC_PF_INT support (Vitaly) > > * i386 XSAVE bugfix (Xiaoyao) > > * QOM developer documentation in docs/devel (Eduardo) > > * new checkpatch tests (Dov) > > * x86_64 syscall fix (Douglas) > > * interrupt-based APF fix (Vitaly) > > * always create kvmclock (Vitaly) > > * fix bios-tables-test (Eduardo) > > * KVM PV features cleanup (myself) > > * CAN FD (Pavel) > > > > meson: > > * fixes (Marc-André, Max, Stefan, Alexander, myself) > > * moved libmpathpersist, cocoa, malloc tests (myself) > > * support for 0.56 introspected test dependencies (myself) > > > > > Applied, thanks. > > Please update the changelog at https://wiki.qemu.org/ChangeLog/5.2 > for any user-visible changes. > > -- PMM > Long awating, wonderfull -- 此致 礼 罗勇刚 Yours sincerely, Yonggang Luo <div dir="ltr"><br><br>On Thu, Oct 1, 2020 at 10:36 PM Peter Maydell <<a href="mailto:peter.maydell@linaro.org">peter.maydell@linaro.org</a>> wrote:<br>><br>> On Wed, 30 Sep 2020 at 21:04, Paolo Bonzini <<a href="mailto:pbonzini@redhat.com">pbonzini@redhat.com</a>> wrote:<br>> ><br>> > The following changes since commit cbba3dc6ea3fc9aa66e9f9eb41051536e3ad7cd0:<br>> ><br>> > Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging (2020-09-30 11:40:38 +0100)<br>> ><br>> > are available in the Git repository at:<br>> ><br>> > <a href="https://gitlab.com/bonzini/qemu.git">https://gitlab.com/bonzini/qemu.git</a> tags/for-upstream<br>> ><br>> > for you to fetch changes up to 37aeb7a28ddbf52dd25dd53ae1b8391bc2287858:<br>> ><br>> > hw/net/can: Correct Kconfig dependencies (2020-09-30 19:11:37 +0200)<br>> ><br>> > ----------------------------------------------------------------<br>> > * SCSI fix (Dmitry, Li Feng, Li Qiang)<br>> > * memory API fixes (Eduardo)<br>> > * removal of deprecated '-numa node', 'cpu-add', '-smp' (Igor)<br>> > * ACPI fix for VMBus (Jon)<br>> > * relocatable install (myself)<br>> > * always remove docker containers (myself)<br>> > * serial cleanups (Philippe)<br>> > * vmware cpuid leaf for tsc and apic frequency (Sunil)<br>> > * KVM_FEATURE_ASYNC_PF_INT support (Vitaly)<br>> > * i386 XSAVE bugfix (Xiaoyao)<br>> > * QOM developer documentation in docs/devel (Eduardo)<br>> > * new checkpatch tests (Dov)<br>> > * x86_64 syscall fix (Douglas)<br>> > * interrupt-based APF fix (Vitaly)<br>> > * always create kvmclock (Vitaly)<br>> > * fix bios-tables-test (Eduardo)<br>> > * KVM PV features cleanup (myself)<br>> > * CAN FD (Pavel)<br>> ><br>> > meson:<br>> > * fixes (Marc-André, Max, Stefan, Alexander, myself)<br>> > * moved libmpathpersist, cocoa, malloc tests (myself)<br>> > * support for 0.56 introspected test dependencies (myself)<br>> ><br>><br>><br>> Applied, thanks.<br>><br>> Please update the changelog at <a href="https://wiki.qemu.org/ChangeLog/5.2">https://wiki.qemu.org/ChangeLog/5.2</a><br>> for any user-visible changes.<br>><br>> -- PMM<br>><br>Long awating, wonderfull<br><br>--<br> 此致<br>礼<br>罗勇刚<br>Yours<br> sincerely,<br>Yonggang Luo</div>
On Wed, 30 Sep 2020 at 21:01, Paolo Bonzini <pbonzini@redhat.com> wrote: > > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> > --- > configure | 14 -------------- > meson.build | 7 ++++--- > 2 files changed, 4 insertions(+), 17 deletions(-) Hi; this commit seems to have broken my static build. Previously configure did not include libudev in the link for a static build (there is no libudev.a, at least on my system). Now it does, and then the link fails with /usr/bin/ld: cannot find -ludev > ########################################## > -# Do we have libudev > -if test "$libudev" != "no" ; then > - if $pkg_config libudev && test "$static" != "yes"; then > - libudev="yes" > - libudev_libs=$($pkg_config --libs libudev) > - else > - libudev="no" > - fi > -fi This is the old code, which doesn't enable libudev for static builds. > --- a/meson.build > +++ b/meson.build > @@ -257,8 +257,8 @@ if 'CONFIG_CURL' in config_host > link_args: config_host['CURL_LIBS'].split()) > endif > libudev = not_found > -if 'CONFIG_LIBUDEV' in config_host > - libudev = declare_dependency(link_args: config_host['LIBUDEV_LIBS'].split()) > +if targetos == 'linux' and (have_system or have_tools) > + libudev = dependency('libudev', static: enable_static) > endif I'm not very confident about reading meson.build logic, but it looks like this trusts meson/pkg-config to tell it about whether it can do a static link against this library, which doesn't work on my system, at least. (Ubuntu 18.04.4). > brlapi = not_found > if 'CONFIG_BRLAPI' in config_host thanks -- PMM
On 01/10/20 18:19, Peter Maydell wrote: > Hi; this commit seems to have broken my static build. > Previously configure did not include libudev in the link > for a static build (there is no libudev.a, at least on my > system). Now it does, and then the link fails with > /usr/bin/ld: cannot find -ludev > >> ########################################## >> -# Do we have libudev >> -if test "$libudev" != "no" ; then >> - if $pkg_config libudev && test "$static" != "yes"; then >> - libudev="yes" >> - libudev_libs=$($pkg_config --libs libudev) >> - else >> - libudev="no" >> - fi >> -fi > > This is the old code, which doesn't enable libudev for > static builds. [...] > I'm not very confident about reading meson.build logic, but it > looks like this trusts meson/pkg-config to tell it about > whether it can do a static link against this library, > which doesn't work on my system, at least. (Ubuntu 18.04.4). Yes, and the same was of course true of pkg-config without meson. You probably got the same warning that you reported on v7. In fact, my guess is that the "test $static != yes" was added in reply to a similar complaint; the commit that introduced it has a note that the test was added by the maintainer: commit 3efac6ebb88e4d099f07fef65178ebaa595ae770 Author: Tomáš Golembiovský <tgolembi@redhat.com> Date: Tue Oct 23 13:23:10 2018 +0200 configure: add test for libudev Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> *make libudev optional to avoid breaking existing build/test environments *disable libudev for --static builds Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> But I don't think --static should affect the build this way, especially since libudev was the only library that had this test in the configure script (checked in 5.1). Debian doesn't package "libgtk-3.a" either and yet GTK+ it is not special cased in the configure script, so I'm not sure what it is that makes libudev special. Do you actually build just with "--static"? Or do you have a list of "--disable" options so you can add one more? Paolo
On Thu, 1 Oct 2020 at 17:55, Paolo Bonzini <pbonzini@redhat.com> wrote: > On 01/10/20 18:19, Peter Maydell wrote: > > I'm not very confident about reading meson.build logic, but it > > looks like this trusts meson/pkg-config to tell it about > > whether it can do a static link against this library, > > which doesn't work on my system, at least. (Ubuntu 18.04.4). > > Yes, and the same was of course true of pkg-config without meson. You > probably got the same warning that you reported on v7. > > In fact, my guess is that the "test $static != yes" was added in reply > to a similar complaint; the commit that introduced it has a note that > the test was added by the maintainer: > > commit 3efac6ebb88e4d099f07fef65178ebaa595ae770 > Author: Tomáš Golembiovský <tgolembi@redhat.com> > Date: Tue Oct 23 13:23:10 2018 +0200 > > configure: add test for libudev > > Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com> > Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> > *make libudev optional to avoid breaking existing build/test > environments > *disable libudev for --static builds > Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com> > > But I don't think --static should affect the build this way, especially > since libudev was the only library that had this test in the configure > script (checked in 5.1). Debian doesn't package "libgtk-3.a" either and > yet GTK+ it is not special cased in the configure script, so I'm not > sure what it is that makes libudev special. > > Do you actually build just with "--static"? Or do you have a list of > "--disable" options so you can add one more? Yes, I have a lot of --disable-foo options. Ideally I wouldn't need any, because our configure/build system would identify "there isn't actually a static version of this dependency present" rather than blindly trusting pkg-config when it lies to us. (Is it possible to get Meson to just always do a "test that a trivial program with these cflags and libs will build" as part of whatever magic it does as part of dependency() ? Or to have a qemu_dependency() wrapper that does ?) The useful thing about libgtk is that it's pretty obvious that the --disable option to use to stop QEMU linking to it is --disable-gtk. It's much less obvious what would be the --disable option to use to stop us linking against libgio, or libudev, because those dependencies aren't closely and obviously tied to QEMU features. So for that kind of library dependency it's much more useful to have configure do enough checks that it doesn't try to link against something that doesn't exist. thanks -- PMM
On 01/10/20 20:51, Peter Maydell wrote: > Yes, I have a lot of --disable-foo options. Ideally I wouldn't > need any, because our configure/build system would identify "there > isn't actually a static version of this dependency present" > rather than blindly trusting pkg-config when it lies to us. > (Is it possible to get Meson to just always do a "test that > a trivial program with these cflags and libs will build" as > part of whatever magic it does as part of dependency() ? Unfortunately there are many special cases, including libraries that require symbols in the executable, so its not possible to do that. For this reason the "static library not found for dependency" is just a warning. We can add such a compile test ourselves. Of course it might add to the compile time if we do it for every dependency, but perhaps we can do one with all the dependencies and if it fails loop on single dependencies to give a better error. Paolo
On 9/30/20 9:58 PM, Paolo Bonzini wrote: > > Eduardo Habkost (10): <snip/> > docs: Create docs/devel/qom.rst cd442a45db60a1a72fcf980c24bd1227f13f8a87 is the first bad commit Sorry for noticing this earlier, but is this known? The build starts failing for me after this commit: /usr/bin/sphinx-build -Dversion=5.1.50 -Drelease= -W -Ddepfile=docs/devel.d -Ddepfile_stamp=docs/devel.stamp -b html -d /home/zippy/work/qemu/qemu.git/build/docs/devel.p /home/zippy/work/qemu/qemu.git/docs/devel /home/zippy/work/qemu/qemu.git/build/docs/devel Running Sphinx v3.2.1 building [mo]: targets for 0 po files that are out of date building [html]: targets for 20 source files that are out of date updating environment: [new config] 20 added, 0 changed, 0 removed reading sources... [100%] testing Warning, treated as error: /home/zippy/work/qemu/qemu.git/docs/../include/qom/object.h:747:Error in declarator If declarator-id with parameters (e.g., 'void f(int arg)'): Invalid C declaration: Expected identifier in nested name. [error at 24] object_initialize_child ( parent, propname, child, type) ------------------------^ If parenthesis in noptr-declarator (e.g., 'void (*f(int arg))(double)'): Error in declarator or parameters Invalid C declaration: Expecting "(" in parameters. [error at 32] object_initialize_child ( parent, propname, child, type) --------------------------------^ make[1]: *** [Makefile.ninja:9898: docs/devel.stamp] Error 2 make[1]: *** Deleting file 'docs/devel.stamp' make[1]: Leaving directory '/home/zippy/work/qemu/qemu.git/build' make: *** [GNUmakefile:11: all] Error 2 Michal
On Fri, Oct 02, 2020 at 05:58:55PM +0200, Michal Prívozník wrote: > On 9/30/20 9:58 PM, Paolo Bonzini wrote: > > > > Eduardo Habkost (10): > <snip/> > > docs: Create docs/devel/qom.rst > > cd442a45db60a1a72fcf980c24bd1227f13f8a87 is the first bad commit > > Sorry for noticing this earlier, but is this known? The build starts failing > for me after this commit: > > /usr/bin/sphinx-build -Dversion=5.1.50 -Drelease= -W -Ddepfile=docs/devel.d > -Ddepfile_stamp=docs/devel.stamp -b html -d > /home/zippy/work/qemu/qemu.git/build/docs/devel.p > /home/zippy/work/qemu/qemu.git/docs/devel > /home/zippy/work/qemu/qemu.git/build/docs/devel > Running Sphinx v3.2.1 > building [mo]: targets for 0 po files that are out of date > building [html]: targets for 20 source files that are out of date > updating environment: [new config] 20 added, 0 changed, 0 removed > reading sources... [100%] testing > > > > > Warning, treated as error: > /home/zippy/work/qemu/qemu.git/docs/../include/qom/object.h:747:Error in > declarator > If declarator-id with parameters (e.g., 'void f(int arg)'): > Invalid C declaration: Expected identifier in nested name. [error at 24] > object_initialize_child ( parent, propname, child, type) > ------------------------^ > If parenthesis in noptr-declarator (e.g., 'void (*f(int arg))(double)'): > Error in declarator or parameters > Invalid C declaration: Expecting "(" in parameters. [error at 32] > object_initialize_child ( parent, propname, child, type) > --------------------------------^ > > make[1]: *** [Makefile.ninja:9898: docs/devel.stamp] Error 2 > make[1]: *** Deleting file 'docs/devel.stamp' > make[1]: Leaving directory '/home/zippy/work/qemu/qemu.git/build' > make: *** [GNUmakefile:11: all] Error 2 I can't reproduce it using Sphinx v2.2.2. I'm still trying to understand what exactly the error means. I really wish we used virtualenv + requirements.txt to require a specific version of Sphinx instead of wasting time dealing a wide range of Sphinx versions.
On 02/10/20 17:58, Michal Prívozník wrote: >> > > cd442a45db60a1a72fcf980c24bd1227f13f8a87 is the first bad commit > > Sorry for noticing this earlier, but is this known? The build starts > failing for me after this commit: > > /usr/bin/sphinx-build -Dversion=5.1.50 -Drelease= -W > -Ddepfile=docs/devel.d -Ddepfile_stamp=docs/devel.stamp -b html -d > /home/zippy/work/qemu/qemu.git/build/docs/devel.p > /home/zippy/work/qemu/qemu.git/docs/devel > /home/zippy/work/qemu/qemu.git/build/docs/devel > Running Sphinx v3.2.1 > building [mo]: targets for 0 po files that are out of date > building [html]: targets for 20 source files that are out of date > updating environment: [new config] 20 added, 0 changed, 0 removed > reading sources... [100%] testing No, this is new. It works with older versions of Sphinx (I have 2.2.2 despite being on Fedora 32 which is pretty recent). For now Sphinx 3 is not supported by kerneldoc, we probably should apply a patch like https://www.spinics.net/lists/linux-doc/msg83277.html Paolo
On Fri, Oct 02, 2020 at 06:27:35PM +0200, Paolo Bonzini wrote: > On 02/10/20 17:58, Michal Prívozník wrote: > >> > > > > cd442a45db60a1a72fcf980c24bd1227f13f8a87 is the first bad commit > > > > Sorry for noticing this earlier, but is this known? The build starts > > failing for me after this commit: > > > > /usr/bin/sphinx-build -Dversion=5.1.50 -Drelease= -W > > -Ddepfile=docs/devel.d -Ddepfile_stamp=docs/devel.stamp -b html -d > > /home/zippy/work/qemu/qemu.git/build/docs/devel.p > > /home/zippy/work/qemu/qemu.git/docs/devel > > /home/zippy/work/qemu/qemu.git/build/docs/devel > > Running Sphinx v3.2.1 > > building [mo]: targets for 0 po files that are out of date > > building [html]: targets for 20 source files that are out of date > > updating environment: [new config] 20 added, 0 changed, 0 removed > > reading sources... [100%] testing > > No, this is new. It works with older versions of Sphinx (I have 2.2.2 > despite being on Fedora 32 which is pretty recent). > > For now Sphinx 3 is not supported by kerneldoc, we probably should apply > a patch like > > https://www.spinics.net/lists/linux-doc/msg83277.html Weird, because we don't use the cdomain extension, and the patch above only disables the cdomain extension. In either case, supporting only Sphinx 2.x by now sounds reasonable. virtualenv+pip makes it simple to install and run a specific Sphinx version, for people who really need it. -- Eduardo
On 10/2/20 6:22 PM, Eduardo Habkost wrote: > On Fri, Oct 02, 2020 at 05:58:55PM +0200, Michal Prívozník wrote: >> On 9/30/20 9:58 PM, Paolo Bonzini wrote: >>> >>> Eduardo Habkost (10): >> <snip/> >>> docs: Create docs/devel/qom.rst >> >> cd442a45db60a1a72fcf980c24bd1227f13f8a87 is the first bad commit >> >> Sorry for noticing this earlier, but is this known? The build starts failing >> for me after this commit: >> >> /usr/bin/sphinx-build -Dversion=5.1.50 -Drelease= -W -Ddepfile=docs/devel.d >> -Ddepfile_stamp=docs/devel.stamp -b html -d >> /home/zippy/work/qemu/qemu.git/build/docs/devel.p >> /home/zippy/work/qemu/qemu.git/docs/devel >> /home/zippy/work/qemu/qemu.git/build/docs/devel >> Running Sphinx v3.2.1 >> building [mo]: targets for 0 po files that are out of date >> building [html]: targets for 20 source files that are out of date >> updating environment: [new config] 20 added, 0 changed, 0 removed >> reading sources... [100%] testing >> >> >> >> >> Warning, treated as error: >> /home/zippy/work/qemu/qemu.git/docs/../include/qom/object.h:747:Error in >> declarator >> If declarator-id with parameters (e.g., 'void f(int arg)'): >> Invalid C declaration: Expected identifier in nested name. [error at 24] >> object_initialize_child ( parent, propname, child, type) >> ------------------------^ >> If parenthesis in noptr-declarator (e.g., 'void (*f(int arg))(double)'): >> Error in declarator or parameters >> Invalid C declaration: Expecting "(" in parameters. [error at 32] >> object_initialize_child ( parent, propname, child, type) >> --------------------------------^ >> >> make[1]: *** [Makefile.ninja:9898: docs/devel.stamp] Error 2 >> make[1]: *** Deleting file 'docs/devel.stamp' >> make[1]: Leaving directory '/home/zippy/work/qemu/qemu.git/build' >> make: *** [GNUmakefile:11: all] Error 2 > > I can't reproduce it using Sphinx v2.2.2. I'm still trying to > understand what exactly the error means. > Same here. > I really wish we used virtualenv + requirements.txt to require a > specific version of Sphinx instead of wasting time dealing a wide > range of Sphinx versions. > I already have a patch that I keep locally to build with v3: diff --git a/docs/qemu-option-trace.rst.inc b/docs/qemu-option-trace.rst.inc index 7e09773a9c..ae83f6a1a8 100644 --- a/docs/qemu-option-trace.rst.inc +++ b/docs/qemu-option-trace.rst.inc @@ -1,7 +1,7 @@ Specify tracing options. -.. option:: [enable=]PATTERN +.. option:: enable=PATTERN Immediately enable events matching *PATTERN* (either event name or a globbing pattern). This option is only That said, I'm not objecting to requiring v2 for now and switching to v3 later. But interestingly, through trial and error I've came across this hack, which allows me to build again. I have no idea why it works: diff --git i/include/qom/object.h w/include/qom/object.h index 27aaa67e63..59c729ebb7 100644 --- i/include/qom/object.h +++ w/include/qom/object.h @@ -762,13 +762,14 @@ bool object_initialize_child_with_propsv(Object *parentobj, * child, sizeof(*child), type, * &error_abort, NULL) */ -#define object_initialize_child(parent, propname, child, type) \ - object_initialize_child_internal((parent), (propname), \ - (child), sizeof(*(child)), (type)) void object_initialize_child_internal(Object *parent, const char *propname, void *child, size_t size, const char *type); +#define object_initialize_child(parent, propname, child, type) \ + object_initialize_child_internal((parent), (propname), \ + (child), sizeof(*(child)), (type)) + /** * object_dynamic_cast: * @obj: The object to cast.
On 02/10/20 19:26, Michal Prívozník wrote: > On 10/2/20 6:22 PM, Eduardo Habkost wrote: >> On Fri, Oct 02, 2020 at 05:58:55PM +0200, Michal Prívozník wrote: >>> On 9/30/20 9:58 PM, Paolo Bonzini wrote: >>>> >>>> Eduardo Habkost (10): >>> <snip/> >>>> docs: Create docs/devel/qom.rst >>> >>> cd442a45db60a1a72fcf980c24bd1227f13f8a87 is the first bad commit >>> >>> Sorry for noticing this earlier, but is this known? The build starts >>> failing >>> for me after this commit: >>> >>> /usr/bin/sphinx-build -Dversion=5.1.50 -Drelease= -W >>> -Ddepfile=docs/devel.d >>> -Ddepfile_stamp=docs/devel.stamp -b html -d >>> /home/zippy/work/qemu/qemu.git/build/docs/devel.p >>> /home/zippy/work/qemu/qemu.git/docs/devel >>> /home/zippy/work/qemu/qemu.git/build/docs/devel >>> Running Sphinx v3.2.1 >>> building [mo]: targets for 0 po files that are out of date >>> building [html]: targets for 20 source files that are out of date >>> updating environment: [new config] 20 added, 0 changed, 0 removed >>> reading sources... [100%] testing >>> >>> >>> >>> >>> Warning, treated as error: >>> /home/zippy/work/qemu/qemu.git/docs/../include/qom/object.h:747:Error in >>> declarator >>> If declarator-id with parameters (e.g., 'void f(int arg)'): >>> Invalid C declaration: Expected identifier in nested name. [error >>> at 24] >>> object_initialize_child ( parent, propname, child, type) >>> ------------------------^ >>> If parenthesis in noptr-declarator (e.g., 'void (*f(int arg))(double)'): >>> Error in declarator or parameters >>> Invalid C declaration: Expecting "(" in parameters. [error at 32] >>> object_initialize_child ( parent, propname, child, type) >>> --------------------------------^ >>> >>> make[1]: *** [Makefile.ninja:9898: docs/devel.stamp] Error 2 >>> make[1]: *** Deleting file 'docs/devel.stamp' >>> make[1]: Leaving directory '/home/zippy/work/qemu/qemu.git/build' >>> make: *** [GNUmakefile:11: all] Error 2 >> >> I can't reproduce it using Sphinx v2.2.2. I'm still trying to >> understand what exactly the error means. >> > > Same here. > >> I really wish we used virtualenv + requirements.txt to require a >> specific version of Sphinx instead of wasting time dealing a wide >> range of Sphinx versions. >> > > I already have a patch that I keep locally to build with v3: > > diff --git a/docs/qemu-option-trace.rst.inc > b/docs/qemu-option-trace.rst.inc > index 7e09773a9c..ae83f6a1a8 100644 > --- a/docs/qemu-option-trace.rst.inc > +++ b/docs/qemu-option-trace.rst.inc > @@ -1,7 +1,7 @@ > > Specify tracing options. > > -.. option:: [enable=]PATTERN > +.. option:: enable=PATTERN > > Immediately enable events matching *PATTERN* > (either event name or a globbing pattern). This option is only > > > That said, I'm not objecting to requiring v2 for now and switching to v3 > later. > > > But interestingly, through trial and error I've came across this hack, > which allows me to build again. I have no idea why it works: > > diff --git i/include/qom/object.h w/include/qom/object.h > index 27aaa67e63..59c729ebb7 100644 > --- i/include/qom/object.h > +++ w/include/qom/object.h > @@ -762,13 +762,14 @@ bool object_initialize_child_with_propsv(Object > *parentobj, > * child, sizeof(*child), type, > * &error_abort, NULL) > */ > -#define object_initialize_child(parent, propname, child, type) \ > - object_initialize_child_internal((parent), (propname), \ > - (child), sizeof(*(child)), (type)) > void object_initialize_child_internal(Object *parent, const char > *propname, > void *child, size_t size, > const char *type); > > +#define object_initialize_child(parent, propname, child, type) \ > + object_initialize_child_internal((parent), (propname), \ > + (child), sizeof(*(child)), (type)) > + The error is due to kerneldoc treating the macro definition like a function, so that makes sense. If the docs look good (no reference to object_initialize_child_internal) then the patch can be applied. Paolo
On Fri, Oct 02, 2020 at 07:30:17PM +0200, Paolo Bonzini wrote: > On 02/10/20 19:26, Michal Prívozník wrote: > > On 10/2/20 6:22 PM, Eduardo Habkost wrote: > >> On Fri, Oct 02, 2020 at 05:58:55PM +0200, Michal Prívozník wrote: > >>> On 9/30/20 9:58 PM, Paolo Bonzini wrote: > >>>> > >>>> Eduardo Habkost (10): > >>> <snip/> > >>>> docs: Create docs/devel/qom.rst > >>> > >>> cd442a45db60a1a72fcf980c24bd1227f13f8a87 is the first bad commit > >>> > >>> Sorry for noticing this earlier, but is this known? The build starts > >>> failing > >>> for me after this commit: > >>> > >>> /usr/bin/sphinx-build -Dversion=5.1.50 -Drelease= -W > >>> -Ddepfile=docs/devel.d > >>> -Ddepfile_stamp=docs/devel.stamp -b html -d > >>> /home/zippy/work/qemu/qemu.git/build/docs/devel.p > >>> /home/zippy/work/qemu/qemu.git/docs/devel > >>> /home/zippy/work/qemu/qemu.git/build/docs/devel > >>> Running Sphinx v3.2.1 > >>> building [mo]: targets for 0 po files that are out of date > >>> building [html]: targets for 20 source files that are out of date > >>> updating environment: [new config] 20 added, 0 changed, 0 removed > >>> reading sources... [100%] testing > >>> > >>> > >>> > >>> > >>> Warning, treated as error: > >>> /home/zippy/work/qemu/qemu.git/docs/../include/qom/object.h:747:Error in > >>> declarator > >>> If declarator-id with parameters (e.g., 'void f(int arg)'): > >>> Invalid C declaration: Expected identifier in nested name. [error > >>> at 24] > >>> object_initialize_child ( parent, propname, child, type) > >>> ------------------------^ > >>> If parenthesis in noptr-declarator (e.g., 'void (*f(int arg))(double)'): > >>> Error in declarator or parameters > >>> Invalid C declaration: Expecting "(" in parameters. [error at 32] > >>> object_initialize_child ( parent, propname, child, type) > >>> --------------------------------^ > >>> > >>> make[1]: *** [Makefile.ninja:9898: docs/devel.stamp] Error 2 > >>> make[1]: *** Deleting file 'docs/devel.stamp' > >>> make[1]: Leaving directory '/home/zippy/work/qemu/qemu.git/build' > >>> make: *** [GNUmakefile:11: all] Error 2 > >> > >> I can't reproduce it using Sphinx v2.2.2. I'm still trying to > >> understand what exactly the error means. > >> > > > > Same here. > > > >> I really wish we used virtualenv + requirements.txt to require a > >> specific version of Sphinx instead of wasting time dealing a wide > >> range of Sphinx versions. > >> > > > > I already have a patch that I keep locally to build with v3: > > > > diff --git a/docs/qemu-option-trace.rst.inc > > b/docs/qemu-option-trace.rst.inc > > index 7e09773a9c..ae83f6a1a8 100644 > > --- a/docs/qemu-option-trace.rst.inc > > +++ b/docs/qemu-option-trace.rst.inc > > @@ -1,7 +1,7 @@ > > > > Specify tracing options. > > > > -.. option:: [enable=]PATTERN > > +.. option:: enable=PATTERN > > > > Immediately enable events matching *PATTERN* > > (either event name or a globbing pattern). This option is only > > > > > > That said, I'm not objecting to requiring v2 for now and switching to v3 > > later. > > > > > > But interestingly, through trial and error I've came across this hack, > > which allows me to build again. I have no idea why it works: > > > > diff --git i/include/qom/object.h w/include/qom/object.h > > index 27aaa67e63..59c729ebb7 100644 > > --- i/include/qom/object.h > > +++ w/include/qom/object.h > > @@ -762,13 +762,14 @@ bool object_initialize_child_with_propsv(Object > > *parentobj, > > * child, sizeof(*child), type, > > * &error_abort, NULL) > > */ > > -#define object_initialize_child(parent, propname, child, type) \ > > - object_initialize_child_internal((parent), (propname), \ > > - (child), sizeof(*(child)), (type)) > > void object_initialize_child_internal(Object *parent, const char > > *propname, > > void *child, size_t size, > > const char *type); > > > > +#define object_initialize_child(parent, propname, child, type) \ > > + object_initialize_child_internal((parent), (propname), \ > > + (child), sizeof(*(child)), (type)) > > + > > The error is due to kerneldoc treating the macro definition like a > function, so that makes sense. If the docs look good (no reference to > object_initialize_child_internal) then the patch can be applied. The patch makes the document show object_initialize_child_internal().
On Fri, Oct 02, 2020 at 06:27:35PM +0200, Paolo Bonzini wrote: > On 02/10/20 17:58, Michal Prívozník wrote: > >> > > > > cd442a45db60a1a72fcf980c24bd1227f13f8a87 is the first bad commit > > > > Sorry for noticing this earlier, but is this known? The build starts > > failing for me after this commit: > > > > /usr/bin/sphinx-build -Dversion=5.1.50 -Drelease= -W > > -Ddepfile=docs/devel.d -Ddepfile_stamp=docs/devel.stamp -b html -d > > /home/zippy/work/qemu/qemu.git/build/docs/devel.p > > /home/zippy/work/qemu/qemu.git/docs/devel > > /home/zippy/work/qemu/qemu.git/build/docs/devel > > Running Sphinx v3.2.1 > > building [mo]: targets for 0 po files that are out of date > > building [html]: targets for 20 source files that are out of date > > updating environment: [new config] 20 added, 0 changed, 0 removed > > reading sources... [100%] testing > > No, this is new. It works with older versions of Sphinx (I have 2.2.2 > despite being on Fedora 32 which is pretty recent). > > For now Sphinx 3 is not supported by kerneldoc, we probably should apply > a patch like > > https://www.spinics.net/lists/linux-doc/msg83277.html We already have Sphinx 3.x hacks inside our fork of kernel-doc, see commit 152d1967f650 ("kernel-doc: Use c:struct for Sphinx 3.0 and later"). If we want to keep deviating from upstream kernel-doc, the following patch seems to work. Do we want to? Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> --- diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 40ad782e342..03b49380426 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -838,6 +838,13 @@ sub output_function_rst(%) { $lineprefix = ""; output_highlight_rst($args{'purpose'}); $start = "\n\n**Syntax**\n\n ``"; + } elsif ($args{'functiontype'} eq "") { + # this is a macro, Sphinx 3.x requires c:macro:: + if ((split(/\./, $sphinx_version))[0] >= 3) { + print ".. c:macro:: "; + } else { + print ".. c:function:: "; + } } else { print ".. c:function:: "; } > > Paolo > -- Eduardo
On 02/10/20 20:24, Eduardo Habkost wrote: > On Fri, Oct 02, 2020 at 06:27:35PM +0200, Paolo Bonzini wrote: >> On 02/10/20 17:58, Michal Prívozník wrote: >>>> >>> >>> cd442a45db60a1a72fcf980c24bd1227f13f8a87 is the first bad commit >>> >>> Sorry for noticing this earlier, but is this known? The build starts >>> failing for me after this commit: >>> >>> /usr/bin/sphinx-build -Dversion=5.1.50 -Drelease= -W >>> -Ddepfile=docs/devel.d -Ddepfile_stamp=docs/devel.stamp -b html -d >>> /home/zippy/work/qemu/qemu.git/build/docs/devel.p >>> /home/zippy/work/qemu/qemu.git/docs/devel >>> /home/zippy/work/qemu/qemu.git/build/docs/devel >>> Running Sphinx v3.2.1 >>> building [mo]: targets for 0 po files that are out of date >>> building [html]: targets for 20 source files that are out of date >>> updating environment: [new config] 20 added, 0 changed, 0 removed >>> reading sources... [100%] testing >> >> No, this is new. It works with older versions of Sphinx (I have 2.2.2 >> despite being on Fedora 32 which is pretty recent). >> >> For now Sphinx 3 is not supported by kerneldoc, we probably should apply >> a patch like >> >> https://www.spinics.net/lists/linux-doc/msg83277.html > > We already have Sphinx 3.x hacks inside our fork of kernel-doc, > see commit 152d1967f650 ("kernel-doc: Use c:struct for Sphinx 3.0 > and later"). > > If we want to keep deviating from upstream kernel-doc, the > following patch seems to work. Do we want to? > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> > --- > diff --git a/scripts/kernel-doc b/scripts/kernel-doc > index 40ad782e342..03b49380426 100755 > --- a/scripts/kernel-doc > +++ b/scripts/kernel-doc > @@ -838,6 +838,13 @@ sub output_function_rst(%) { > $lineprefix = ""; > output_highlight_rst($args{'purpose'}); > $start = "\n\n**Syntax**\n\n ``"; > + } elsif ($args{'functiontype'} eq "") { > + # this is a macro, Sphinx 3.x requires c:macro:: > + if ((split(/\./, $sphinx_version))[0] >= 3) { > + print ".. c:macro:: "; > + } else { > + print ".. c:function:: "; > + } > } else { > print ".. c:function:: "; > } >> >> Paolo >> > I can try sending these to upstream Linux, too. Paolo
On Fri, 2 Oct 2020 at 19:45, Paolo Bonzini <pbonzini@redhat.com> wrote: > On 02/10/20 20:24, Eduardo Habkost wrote: > > We already have Sphinx 3.x hacks inside our fork of kernel-doc, > > see commit 152d1967f650 ("kernel-doc: Use c:struct for Sphinx 3.0 > > and later"). > > > > If we want to keep deviating from upstream kernel-doc, the > > following patch seems to work. Do we want to? > I can try sending these to upstream Linux, too. I did mention the c:struct change we're carrying to Jon Corbet when I sent him the missing-close-paren fix to kernel-doc earlier this year: http://lkml.iu.edu/hypermail/linux/kernel/2004.1/08760.html I think it probably mostly needs somebody to try these changes in the context of producing the kernel docs and see if they are sufficient to fix kernel doc production too... thanks -- PMM
On 10/2/20 8:24 PM, Eduardo Habkost wrote: > On Fri, Oct 02, 2020 at 06:27:35PM +0200, Paolo Bonzini wrote: >> On 02/10/20 17:58, Michal Prívozník wrote: >>>> >>> >>> cd442a45db60a1a72fcf980c24bd1227f13f8a87 is the first bad commit >>> >>> Sorry for noticing this earlier, but is this known? The build starts >>> failing for me after this commit: >>> >>> /usr/bin/sphinx-build -Dversion=5.1.50 -Drelease= -W >>> -Ddepfile=docs/devel.d -Ddepfile_stamp=docs/devel.stamp -b html -d >>> /home/zippy/work/qemu/qemu.git/build/docs/devel.p >>> /home/zippy/work/qemu/qemu.git/docs/devel >>> /home/zippy/work/qemu/qemu.git/build/docs/devel >>> Running Sphinx v3.2.1 >>> building [mo]: targets for 0 po files that are out of date >>> building [html]: targets for 20 source files that are out of date >>> updating environment: [new config] 20 added, 0 changed, 0 removed >>> reading sources... [100%] testing >> >> No, this is new. It works with older versions of Sphinx (I have 2.2.2 >> despite being on Fedora 32 which is pretty recent). >> >> For now Sphinx 3 is not supported by kerneldoc, we probably should apply >> a patch like >> >> https://www.spinics.net/lists/linux-doc/msg83277.html > > We already have Sphinx 3.x hacks inside our fork of kernel-doc, > see commit 152d1967f650 ("kernel-doc: Use c:struct for Sphinx 3.0 > and later"). > > If we want to keep deviating from upstream kernel-doc, the > following patch seems to work. Do we want to? > > Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> > --- > diff --git a/scripts/kernel-doc b/scripts/kernel-doc > index 40ad782e342..03b49380426 100755 > --- a/scripts/kernel-doc > +++ b/scripts/kernel-doc > @@ -838,6 +838,13 @@ sub output_function_rst(%) { > $lineprefix = ""; > output_highlight_rst($args{'purpose'}); > $start = "\n\n**Syntax**\n\n ``"; > + } elsif ($args{'functiontype'} eq "") { > + # this is a macro, Sphinx 3.x requires c:macro:: > + if ((split(/\./, $sphinx_version))[0] >= 3) { > + print ".. c:macro:: "; > + } else { > + print ".. c:function:: "; > + } > } else { > print ".. c:function:: "; > } >> >> Paolo >> > I can confirm that this fixes the build for me. Michal