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 -- http://mail.python.org/mailman/listinfo/python-list