[sword-devel] Development, SWIG Bindings, etc...

[Greg Hellings]

On Mon, Jan 9, 2012 at 1:04 PM, Paul A. Martel <pmartel60 at gmail.com> wrote:
> Brian,
> You might benefit from my experience, limited as it is. I have a
> windows dev box with the free version of MSVS installed. I tried
> following wiki instructions at
> http://www.crosswire.org/wiki/Tutorial:Compiling_%26_Installing_SWORD_on_Windows
> but got stuck. I don't know why. It looked like a problem in how the
> project file was defined.  I am pretty sure that I was using a newer
> version of the MSVS tools than the wiki author, but I don't know if
> that had anything to do with it. Also, the issue seemed to be related
> to issues surrounding a 32-bit vs. a 64-bit build, so maybe the
> problem was my 32-bit machine.

The MSVS files are maintained by Chris Little. They remain the
official way that he makes releases of the SWORD utilities, and he
just updated them a small number of weeks ago to an updated version of
MSVS. You might give them a go again, but Visual Studio is most
definitely supported by SWORD for building on Windows. BibleTime
Windows releases are made using Visual Studio on a regular basis as
well.

>
> When I asked about the issue here, the response I got was that I was
> probably better off cross-compiling from SUSE using mingw.
> Soon thereafter instructions for doing just that appeared on that wiki
> page. AFAICT, that cross-compilation approach or something very much
> like it may have been the defacto way to do a windows build for over a
> year now. Of course, feel free to buy your windows machine and solve
> these issues and make the world safe for MSVS sword builds, but I
> haven't heard of anyone else (possibly excluding myself) that would
> immediately benefit from this work.
> I also don't know if there is an up-to-date non-MSVS windows native
> build method for sword that uses gcc and/or mingw and/or cygwin.

Cross-compiling from Linux using Fedora, SuSE or the recent set of
Ubuntu tools I've put together is relatively straightforward. Just
invoke CMake with the proper Toolchain file and you're all set. Once
I'm certain that the existing Toolchain files work well I'm going to
commit them to SVN so that others can use them if they ever want to
cross-compile.

Building in MSYS is also relatively straightforward using either
autotools or CMake. Just invoke them as your normally would. Building
with Cygwin is not recommended unless you are sure you know what
you're doing. If you slip up you can end up introducing long chains of
dependencies on Cygwin libraries that you might not want to limit
yourself to.

>
> I'm also not sure what demand there is for (continued?) wchar_t
> support through SWIG. I could be wrong, but my impression was that
> there was a strong bias towards using UTF-8 throughout the sword call
> stack except where Windows insisted on using 16-bit wchar_t for
> interaction with its file system and environment settings. In fact, my
> main reason for trying to do a build on windows was to try to further
> isolate these few cases and to wrap those windows apis that provided
> the only means of supporting non-ASCII (especially in file and path
> names) with functions that did utf-8 conversions.
> But, as I said, I got stuck in build issues. I decided to put off the
> suggested workaround of installing Suse and I moved on to other
> projects. It may be that the problem of adding those wchar_t to utf-8
> conversion has since been solved in whole or in part by someone with a
> sharper mind and/or sharper tools than I have, but, if so, that has
> escaped my notice.

The SWIG compilation issues only arose very recently when the UTF-8
--> UTF-16 conversion methods were put in place to more easily
accommodate Windows calls. The library still uses the old C API,
because there hasn't been much need for the UTF compatibility, but
fixing that bug is one of the big points that should (hopefully)
appear in the next releases of the SWORD engine.

--Greg