[sword-devel] Development, SWIG Bindings, etc...
Paul A. Martel
pmartel60 at gmail.com
Mon Jan 9 12:04:50 MST 2012
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.
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.
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.
That's just one noob's perspective on points that seem worth discussing.
In Christ,
--paul
On Sat, Jan 7, 2012 at 5:59 PM, brian <brianlovesjesus at perffection.com> wrote:
>
> Hey Everyone, God bless you
> Hope you are enjoying your Saturday. Thank you for your welcoming notes (public/private) and ideas. I am looking more into the code, and different projects. I'd like to help with Xyphos, or the windows software if I can get it to compile with mingw or find a windows dev box, though right now i'm looking more into SWIG.
> To get SWIG to work on the SVN branch (This is to get it to compile, and it allows it to work but I still haven't gone over all the warnings which seem mostly due to operator overloading) , the problem lies in that SWBuf::append(wchar_t) which is new is not yet fully supported by SWIG. We can remove its usage by editing swbuf.i and adding at line 29:
>
> %ignore sword::SWBuf::append(wchar_t);
>
> SWBuf::append will still work for other datatypes like char.
>
> another option is to edit sword.i (or the swig interface files) and add functionality for wchar. I am still testing it, but adding something like this on line 9 should work for now:
>
> %fragment("SWIG_AsVal_wchar_t", "header", fragment="<wchar.h>") {
> SWIGINTERN int SWIG_AsVal_wchar_t(SV* p, wchar_t* val) {
> long v;
> int res;
> res = SWIG_AddCast(SWIG_AsVal_long(p, &v));
> if (SWIG_IsOK(res)) {
> if (val) *val = static_cast< wchar_t >(v);
> }
> return res;
> }
> }
>
> either solution will allow compilation and useful functionality. On SVN i've needed to alter the makefiles that are included by sword to get it to compile the final library. I will try to spend some time making the bindings compile and work. If any of you can try out the rsword gem it would be neat (gem install rsword), and any general comments to be able to make it ready for production.
>
> In Christ, God bless you
> -brian
>
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel
mailing list