[Distutils] UCS-2/4 conflicts in distutils-produced RPM

[M.-A. Lemburg]

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/