UCS-2/4 conflicts in distutils-produced RPM
I've just hit a major pblm with a package I distribute which includes extension code which in turn uses Unicode functions -- it fails if the UCS2/UCS4 build state of the source/target are not the same. I've checked the archives and can't see anything about this -- is this a known problem? What's the recommended solution? Thanks ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh W3C Fellow 1999--2002, part-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
Henry S. Thompson wrote:
I've just hit a major pblm with a package I distribute which includes extension code which in turn uses Unicode functions -- it fails if the UCS2/UCS4 build state of the source/target are not the same. I've checked the archives and can't see anything about this -- is this a known problem?
Yes. See the Python FAQ.
What's the recommended solution?
Distribute two RPMs: one for UCS2 builds and one for UCS4 builds. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
"M.-A. Lemburg" <mal@lemburg.com> writes:
Henry S. Thompson wrote:
I've just hit a major pblm with a package I distribute which includes extension code which in turn uses Unicode functions -- it fails if the UCS2/UCS4 build state of the source/target are not the same. I've checked the archives and can't see anything about this -- is this a known problem?
Yes. See the Python FAQ.
I meant a known problem for distutils specifically.
What's the recommended solution?
Distribute two RPMs: one for UCS2 builds and one for UCS4 builds.
I had figured _that_ much out for myself :-) What I meant was, is there a generic approach in view for distutils in general, e.g. by making provision in Extension for specifying a Unicode dependency, which would in turn surface in the bdist name and/or in an install-time test? ht -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh W3C Fellow 1999--2002, part-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
Henry S. Thompson wrote:
"M.-A. Lemburg" <mal@lemburg.com> writes:
Henry S. Thompson wrote:
I've just hit a major pblm with a package I distribute which includes extension code which in turn uses Unicode functions -- it fails if the UCS2/UCS4 build state of the source/target are not the same. I've checked the archives and can't see anything about this -- is this a known problem?
Yes. See the Python FAQ.
I meant a known problem for distutils specifically.
Well, I suppose that distutils package authors should be made more aware of the problem. Note however, that the problem only surfaces in case you actually use Unicode in your C extension.
What's the recommended solution?
Distribute two RPMs: one for UCS2 builds and one for UCS4 builds.
I had figured _that_ much out for myself :-)
Thought so :-)
What I meant was, is there a generic approach in view for distutils in general, e.g. by making provision in Extension for specifying a Unicode dependency, which would in turn surface in the bdist name and/or in an install-time test?
It would probably make sense to have the information go into the bdist name, but I don't see how this could be accomplished. The Python version used for building the extension decides whether you are building UCS2 or 4 -- there's no distutils option for this (simply because its a configure time feature of Python). So in the end, the packager is in control here and she could also make sure that either the name or the info with which she distributes the package carries that information. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH _______________________________________________________________________ eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,... Python Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
participants (2)
-
Henry S. Thompson -
M.-A. Lemburg