Re: [Xen-devel] minimum Python version

[Juergen Gross <jgross@xxxxxxxx>]

On 20/09/17 09:00, Jan Beulich wrote:
> Hello,
> 
> for quite a while (apparently as of Marek's series in February) I've
> been seeing
> 
> xen/lowlevel/xc/xc.c: In function ‘pyxc_dom_extract_cpuid’:
> xen/lowlevel/xc/xc.c:692:13: error: implicit declaration of function 
> ‘PyBytes_AS_STRING’ [-Werror=implicit-function-declaration]
> xen/lowlevel/xc/xc.c:692:21: error: assignment makes pointer from integer 
> without a cast [-Werror]
> xen/lowlevel/xc/xc.c: In function ‘pyxc_create_cpuid_dict’:
> xen/lowlevel/xc/xc.c:707:29: error: implicit declaration of function 
> ‘PyBytes_FromString’ [-Werror=implicit-function-declaration]
> xen/lowlevel/xc/xc.c:707:29: error: passing argument 3 of 
> ‘PyDict_SetItemString’ makes pointer from integer without a cast [-Werror]
> In file included from /usr/include/python2.4/Python.h:94:0,
>                  from xen/lowlevel/xc/xc.c:7:
> /usr/include/python2.4/dictobject.h:128:17: note: expected ‘struct PyObject 
> *’ but argument is of type ‘int’
> xen/lowlevel/xc/xc.c: In function ‘pyxc_readconsolering’:
> xen/lowlevel/xc/xc.c:931:5: error: implicit declaration of function 
> ‘PyBytes_FromStringAndSize’ [-Werror=implicit-function-declaration]
> xen/lowlevel/xc/xc.c:931:9: error: assignment makes pointer from integer 
> without a cast [-Werror]
> xen/lowlevel/xc/xc.c: In function ‘PyXc_dealloc’:
> xen/lowlevel/xc/xc.c:2650:5: error: implicit declaration of function 
> ‘Py_TYPE’ [-Werror=implicit-function-declaration]
> xen/lowlevel/xc/xc.c:2650:18: error: invalid type argument of ‘->’ (have 
> ‘int’)
> cc1: all warnings being treated as errors
> 
> on an older system having Python 2.4 on it. The minimum version
> configure checks for appears to be 2.3, matching up with what
> ./README says. Since the Python bindings aren't something one
> absolutely needs (afaict), wouldn't it be reasonable to check for
> a suitable version and if that fails simply disable their building
> (which currently is unconditional)? What I'd like to avoid is ending
> up with being unable to build the tools on that system - I know
> it's rather old, but there's a reason I'd like to keep it (including its
> old distro level).

Hmm, remembers me to my attempt removing most of the python bindings in
2015.

I think we should try to avoid such problems in the future by (at least)
adding a comment to xen/lowlevel/xc/xc.c that any enhancement should be
done only in case of a real need. New bindings should only be added with
mentioning who will need this binding in the commit message. Existing
bindings should rather be deleted than updated in case an underlying
libxc function is being modified (unless there is a user of that
binding, of course).

For your case: what about adding a configure option to disable building
the python bindings (and any dependencies like e.g. pygrub) instead of
doing so in case of a version mismatch? This would avoid any surprises
in case someone didn't notice that the bindings have been disabled.


Juergen


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel