On Mon, Aug 31, 2009 at 03:59:33PM -0400, Aaron M. Ucko wrote: > Kumar Appaiah <a.ku...@alumni.iitm.ac.in> writes: > > > The fix is simple: either their new npy_endian.h method is broken, > > since it does not attempt to find the endian.h present on all Debian > > machines, or I have not figured out how to force the use of > > endian.h. A simple workaround I'd suggest is to path the npy_endian.h > > provided to force the use of endian.h, for that is the most general > > way and sure to work on all Debian systems. However, before resorting > > to patching, I wanted know if someone can suggest a more elegant > > method to get around this problem, which I haven't been able to figure > > out. > > In general, it's fine to assume endian.h on Debian. For broader > portability, though, I'd add the following suggestions to the one from > #544291: > > - Fix numpy's build system to #define NPY_HAVE_ENDIAN_H as > appropriate, and npy_endian.h to #include "numpyconfig.h". > > - Per pyconfig.h, take advantage of the fact that GCC predefines > __BIG_ENDIAN__ or __LITTLE_ENDIAN__ as appropriate. (Numpy's > headers shouldn't actually #include <pyconfig.h>, of course, just > learn from it.) > > - Fall back on trying <endian.h> rather than #error-ing out, on the > grounds that a possible error is better than a guaranteed one.
Thanks Aaron. I'll let upstream know of this. Kumar -- Kumar Appaiah -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
