M
Maciej (Matchek) Bliziński
Hello python-list,
I'm looking into creating a 32/64-bit Python (2.x and/or 3.x) package
for Solaris. The specificity of that package is that I need to include
both 32-bit and 64-bit binaries in it. The exact way in which the
32/64 support is done is described at [1].
There currently is a Python package that I maintain, which is 32-bit only[2].
I have made an attempt to build a 64-bit package, and my findings are
that the ${prefix}/lib/pythonX.Y/_sysconfigdata.py file contains
system-specific information. Note that it's not ${libdir}/pythonX.Y -
that would have worked, because I'm specifying different ${libdir}
directories when running the 32-bit and 64-bit builds. The Python
installer specifically uses ${prefix}/lib/pythonX.Y. For the most part
is fine, because most of files in there are not architecture-specific,
and it would be quite good to share them among the 32-bit and 64-bit
binaries at runtime. The problem is that some files differ. I've
described it some more at [3].
Ideally, I'd make _sysconfigdata.py return/set different values
depending on the Python runtime that reads it. Something like:
if we're 64-bit:
set values for the 64-bit platform
else:
set values for the 32-bit platform
It's a similar approach to how we currently handle C header files. See
the 'Development packages' section in [1] for more information.
The problem is that it would involve somewhat intrusive patching of
the Python source code, and in long term that means maintainability
issues.
Has this issue been seen before? Is there a better solution? Is there
something that can be done upstream to accommodate this kind of
packaging?
Maciej
[1] http://www.opencsw.org/manual/for-maintainers/32-bit-and-64-bit.html
[2] http://www.opencsw.org/packages/python/
[3] http://lists.opencsw.org/pipermail/maintainers/2013-January/017583.html
I'm looking into creating a 32/64-bit Python (2.x and/or 3.x) package
for Solaris. The specificity of that package is that I need to include
both 32-bit and 64-bit binaries in it. The exact way in which the
32/64 support is done is described at [1].
There currently is a Python package that I maintain, which is 32-bit only[2].
I have made an attempt to build a 64-bit package, and my findings are
that the ${prefix}/lib/pythonX.Y/_sysconfigdata.py file contains
system-specific information. Note that it's not ${libdir}/pythonX.Y -
that would have worked, because I'm specifying different ${libdir}
directories when running the 32-bit and 64-bit builds. The Python
installer specifically uses ${prefix}/lib/pythonX.Y. For the most part
is fine, because most of files in there are not architecture-specific,
and it would be quite good to share them among the 32-bit and 64-bit
binaries at runtime. The problem is that some files differ. I've
described it some more at [3].
Ideally, I'd make _sysconfigdata.py return/set different values
depending on the Python runtime that reads it. Something like:
if we're 64-bit:
set values for the 64-bit platform
else:
set values for the 32-bit platform
It's a similar approach to how we currently handle C header files. See
the 'Development packages' section in [1] for more information.
The problem is that it would involve somewhat intrusive patching of
the Python source code, and in long term that means maintainability
issues.
Has this issue been seen before? Is there a better solution? Is there
something that can be done upstream to accommodate this kind of
packaging?
Maciej
[1] http://www.opencsw.org/manual/for-maintainers/32-bit-and-64-bit.html
[2] http://www.opencsw.org/packages/python/
[3] http://lists.opencsw.org/pipermail/maintainers/2013-January/017583.html