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. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?...@monk.mit.edu -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
