Re: [PULL v8 00/86] Misc QEMU patches for 2020-09-24

[Paolo Bonzini]

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