On 6/1/06, Alex Young <[EMAIL PROTECTED]> wrote: > David Balmain wrote: > > On 6/1/06, Alex Young <[EMAIL PROTECTED]> wrote: > >> Hi there, > >> > >> What's the current status of the Windows port? I may be in a position > >> to lend a hand over the next couple of weeks - where should I start > >> looking? > > > > Hi Alex, > > > > Thanks for your interest. I got Ferret to compile with Visual Studio > > Express 2005. Unfortunately you currently need to use Visual C 6 to > > create Ruby bindings. > A few groups have been bitten by this. I believe this is something Curt > Hibbs is going to be addressing with the next One-Click Installer. I > don't know if you've been following ruby-lang, but there are noises to > move over to a mingw32 build instead of a VC6, which would sort a *lot* > of things out. If that ends up happening, extension building on Windows > will get much simpler. As far as I know, the OCI only uses VC6 because > it was believed at the time that it would be compatible with mingw32 > extensions.
Actually the main reason I haven't finished porting to Windows yet is that it seemed like too much work if the one-click installer is going to change to mingw32 anyway. I hope it happens soon. > For my purposes, I don't especially mind building my own Ruby to make > Ferret compatible with it, but I can see that approach may not have too > many adherents :-) Do you see any reason why that wouldn't work with > the current Ferret source? Would that not be the shortest path to > getting it working? Yes, this would probably be the shortest path to get it working. Plus you'll have much better locale support (ie utf-3 support). > > This proved a lot more difficult so I decided to > > take a different route. Marvin Humphrey (author of KinoSearch, a perl > > port of lucene) and I are about to start a new project at Apache > > called Lucy (http://wiki.apache.org/jakarta-lucene/LucyProposal) which > > will aim to create a C port of Lucene that can be used as a backend in > > all dynamic languages. This time around, portability will be a much > > higher priority. > I'm sure you've considered this, but what does that add compared to a > GCJ+SWIG approach, as with PyLucene? Without having looked at it, is > there anything which prevents that method from being applied to Ruby? It can be done but it's still a lot of work and I just didn't feel up to the task. Plus we get better performance this way with a much smaller download. > > Lucy may or may not one day become the back end to Ferret. At the same > > time I'm experimenting with some different options using the Ferret > > codebase. Now that Lucy is happening I'm not going to worry about > > Lucene index compatibility (which was currently still a long way off > > in Ferret due to Java's modified UTF-8 encoding). This experimental > > code is in; > > > > svn://www.davebalmain.com/exp > > > > This code is much more portable and will compile with VC6. So if you > > want a Windows port quickly you can try merging this code back into > > Ferret propper. Or if you are really interested in the libraries > > internals you could join me working on this experimental code or join > > Marvin and I on the Lucy project (still waiting on Apache approval). > > Whichever route you chose your help will be most appreciated. Let me > > know your thoughts. > From my personal point of view, I'm most interested in having the same > codebase work fast on both Linux and Windows, and, like I say, I don't > mind rebuilding Ruby to do it. Right now, I'd be most interested in > patching the current cFerret to work under mingw32, unless you know of > any reasons that's just not going to work. I'll certainly take a look > at the new code and see if there's anything I can usefully add there, too. Have fun. I don't think it'll be too much work getting it to compile under mingw32. I guess we'll see. Cheers, Dave _______________________________________________ Ferret-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/ferret-talk
