[sword-devel] swbyteswap.h

[Chris Little]

> I don't know about Solaris but byteswap.h is on Debian Sparc, so the
> #ifdef PPC isn't needed.

byteswap.h is part of glibc, so it should be present on any GNU system
(and it probably won't be present on Solaris).  We've got a few
different options here, since really the only thing that keeps Sword
from being compiled on all big endian systems is byte order and we're
doing the fixes one system at a time.  We could continue our current
course, supporting new systems as we are able.  We could integrate the
byteswap.h code directly into Sword -- which might nullify any
processor-specific optimizations for byte swapping.  Or we could change
the ifdefs so that Mac OS X and Solaris Sparc call their respective byte
swappers, while anything else simply defines BIGENDIAN and calls the
macros in byteswap.h.  For that we could define something like system =
gnu_bigendian in Makefile.cfg.
 
> I'm fairly sure that'll fix a longstanding problem, thanks Chris for
> your work on PowerPC :)
>
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=103732&repeatmerged=yes

Cool. :)  I didn't even realize there was a problem.  If I had we
probably could have solved this sooner since Troy had already laid the
groundwork through the Solaris Sparc & Mac OS X byte swapping code.

> Would it be possible to make another minor release soon, or shall I
> just integrate this into 1.5.2 for debian?

I've got some buggy code in CVS right now that I still want to fix (but
I can do that this week) and I want to get Sword compiling on BSD (my
task today) and Mac OS X (should be a piece of cake once these BSD vs.
GNU tools differences can be worked out).  After that, and anything else
anyone thinks can & should be added before another minor unstable
release, I'd support rolling 1.5.3 out the door.  There's no reason why
we shouldn't do more frequent unstable point releases, and it might help
us get bug reports to help with the stable.

--Chris