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

[Andrew Bartlett]

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. 

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba