[PATCHES] Port pytalloc to Python 3
pviktori at redhat.com
Mon Dec 22 10:12:45 MST 2014
On 12/06/2014 10:29 PM, Jelmer Vernooij wrote:
> Hi Petr,
> Thanks for the updated patchset.
> On Fri, Dec 05, 2014 at 10:52:42AM +0100, Petr Viktorin wrote:
>> On 11/28/2014 06:29 PM, Jelmer Vernooij wrote:
>>>> From 9908f55c38ac7e69c96d094065e3f312c963f293 Mon Sep 17 00:00:00 2001
>>>> From: Petr Viktorin <pviktori at redhat.com>
>>>> Date: Wed, 12 Nov 2014 16:53:33 +0100
>>>> Subject: [PATCH 1/4] buildtools: Honor LDVERSION when looking for Python
>>> ^^ Waf patches should go to waf upstream first. We can then update our copy of waf in Samba.
>> The patch was accepted to upstream waf's 1.5 branch
>> Samba's copy has diverged though, there are BSD fixes upstream and a
>> cross-compiling patch only in Samba.
> I've forwarded those upstream a couple of days ago; the cross compiling patch should be the
> only one left and we might be able to drop that (I need a cross-compiling expert to confirm
>>>> diff --git a/lib/talloc/wscript b/lib/talloc/wscript
>>>> index 986492ccde8c7cdac830dc237893775a2682b2fd..57c0faae778c0427859668e3c5b478f62670af97 100644
>>>> --- a/lib/talloc/wscript
>>>> +++ b/lib/talloc/wscript
>>>> @@ -113,21 +113,25 @@ def build(bld):
>>>> if not bld.CONFIG_SET('USING_SYSTEM_PYTALLOC_UTIL') and not bld.env.disable_python:
>>>> - bld.SAMBA_LIBRARY('pytalloc-util',
>>>> + if bld.env.PYTHON_VERSION >= '3':
>>> ^^ How hard would it be to build with all Python versions found rather than
>>> just the one that we found first? That would make preventing regressions with
>>> python3 a lot easier.
>> I'm afraid that would end up being a major refactoring in Waf – all the
>> PYTHON* configuration in the build system assumes a single Python version
>> for the entire build, so we'd have to add some way to have two parallel
>> configurations for anything that touches Python.
>> If Samba ends up supporting both Python versions only for a short time,
>> (except the small stand-alone libraries), then it definitely wouldn't be
>> worth the effort. Otherwise, it probably also wouldn't, but I would look
>> into it more in that case.
> Like ab says, I think this would be important to do if we are going to support
> two Pythons for a while. Not supporting building with multiple python versions here
> is pushing the responsibility for building talloc with multiple pythons out to all
> the packagers.
I am looking into adding a "build for both Pythons" option for the build
scripts. It looks like it will be possible to do, after all.
> Related to this, can we get python3-dev installed on sn-devel so that
> autobuild builds the python3 bindings?
>> From 27e5087868a7790d1fb94f432ef5ba69dbc0cb45 Mon Sep 17 00:00:00 2001
>> From: Petr Viktorin <pviktori at redhat.com>
>> Date: Wed, 12 Nov 2014 16:53:33 +0100
>> Subject: [PATCH v2 1/4] buildtools: Honor LDVERSION when looking for Python
>> diff --git a/lib/talloc/pytalloc.h b/lib/talloc/pytalloc.h
>> index 5c3876ed156a58aa23ea15193c234a5edf46277d..608328e6aca36336b38a5ce6b6a742f1a02facfd 100644
>> --- a/lib/talloc/pytalloc.h
>> +++ b/lib/talloc/pytalloc.h
>> @@ -52,6 +52,8 @@ PyObject *pytalloc_reference_ex(PyTypeObject *py_type, TALLOC_CTX *mem_ctx, void
>> #define pytalloc_new(type, typeobj) pytalloc_steal(typeobj, talloc_zero(NULL, type))
>> +#if PY_MAJOR_VERSION < 3
>> PyObject *pytalloc_CObject_FromTallocPtr(void *);
> ^^ This function should be marked deprecated in the Python2 version; we'll have
> to migrate all code that uses it away from it anyway. I don't think that (marking it
> deprecated) needs to happen in this patchset though.
> Other than that, changes LGTM.
What would be the next step towards getting this merged? Does it depend
on the build system improvements?
More information about the samba-technical