[PATCHES] Build pytalloc for two Python versions at once, port to py3

[Petr Viktorin]

On 02/25/2015 07:53 PM, Andrew Bartlett wrote:
> On Wed, 2015-02-25 at 18:15 +0100, Petr Viktorin wrote:
>> On 01/28/2015 05:42 PM, Petr Viktorin wrote:
>>> Hello,
>>> Here are buildsystem changes needed to build pytalloc for both Python 2
>>> and Python 3 at the same time. This is enabled by configuring with
>>> "--extra-python=/usr/bin/python3". I'm including the Python3 porting
>>> patches I sent earlier, as there are minor changes.
>>>
>>> How this works: The configure step is done using the existing waf
>>> machinery, by swapping the Python-related env variables between a set
>>> for Python2 (the "main Python") and one for Python3 ("extra python").
>>> During build, new features for the "extra python" are used, which leads
>>> to some duplication.
>>>
>>> This could be used to build for e.g. python3.4 & python3.5 at once, but
>>> I haven't tested that. If this is useful in the future I can work on it
>>> more, otherwise all the extrapython stuff can be dropped after the
>>> transition to Python 3.
>>> One thing that would be required for coexistence of the two versions is
>>> ABI-tagging any Python3 extension shared library, e.g.
>>> "libpytalloc-util.cpython-34m.so". I think that's a good idea, but let's
>>> hear your opinions.
>>>
>>> The new configure option is added to all of Samba since it affects all
>>> of the build, even though only talloc uses it. Maybe it should only be
>>> used in individual libraries' configure scripts?
>>> Anything that talloc doesn't need (like binaries or .py files) is not
>>> addressed here – that'd be part of porting the bits that need it.
>>
>> ping
>> Could anyone take some time to look at the patches? I'd like to confirm
>> that this is the right approach before I port other libraries.
>
> I'm concerned by the changes in our C bindings, and would like to see a
> broader sample of the changes before I commit to us going down this
> path.  I realise it dumps a whole pile of risk on you, but my issue is
> that pytalloc is so small as not to be a helpful guide.
>
> As examples, I'm particularly concerned with what the interface for and
> user users of our ldb and ndr generated code will look like.
>
> In particular, in ldb, we transport binary data and string data in the
> same ldb_val structures, and other than by convention and schema, there
> is no indication as to what one might find, yet adding binary2unicode
> conversions all over all our scripts would be a total nightmare.

Hello,
I understand the concern, the unicode/bytes split will undoubtedly be 
the hardest part of the port.
But that's part of the reason why I chose talloc, which doesn't deal 
with strings, to get the buildsystem changes down. IOW, this is not 
about the ldb/ndr interfaces.

My assumption here is that Samba will need to port eventually, so there 
will be some time when we need to build for both 2 and 3 at the same 
time, at least for some parts. I believe that is true regardless of how 
(for example) the bytes/unicode split is handled. Do you have a 
different opinion here?
I'd really like to have the buildsystem changes vetted before I tackle 
the split, so I (and also the future reviewers) can focus on the porting 
itself.


-- 
Petr Viktorin