Re: Fwd: GoXapian
Dave Courtois <[email protected]>
| Newsgroups | gmane.comp.search.xapian.general |
|---|---|
| Message-ID | <CADhZU57JHcQYcab-_fMeix_Q9QiuPe4kdVFyM4fiUsyotLRbTw@mail.gmail.com> |
Hi Olly, I setup the environment for the golang branch and build it without problem. Cgo complain about the generated cc file and dosent regonize it as swig generated file... curious. There no more problem with the MSet and ESet and all class seem to be generated in Go correctly. I will try tomorrow to manually invoke swig over your .i file and see if the code is generated properly. The file generate-go-execption seem to be for python, is it part of the go binding? I see there is xapian_gc.cc I hope that will work, it's be welcome to not have to manage memory allocation manually. I will try to make it work tomorrow, it's late here. It's a good starting point. I know Xapian can work well in go, so it's only a matter of time before I made your version pass the test. have a good night. Dave Le dim. 11 nov. 2018 à 18:10, Olly Betts <[email protected]> a écrit : > On Mon, Nov 05, 2018 at 09:04:23PM +0000, Olly Betts wrote: > > Dave Courtois wrote: > > > Hi there just a little word to tell you that Xapian 1.4.6 work in > > > Golang 1.9. There is some issue with the MSet ESet, the namespace part > > > of the name is drop by swig. There is also some error with define > > > macro in .i files, but with minor change all work perfectly. > > I had a look and I think that at least the macro changes are only needed > because the golang branch hasn't been updated for ages. > > SWIG has a "%nspace" feature to support wrapping namespaces, but it > isn't implemented for Go yet. However, Xapian's C++ API doesn't make > much use of namespaces beyond the top-level Xapian namespace, and I'd > expect in Go that the Go package name would fulfil the same purpose > as the C++ namespace name - i.e. C++ Xapian::MSet -> Go xapian.MSet > and so on. > > I've merged the current RELEASE/1.4 branch into the golang branch and > pushed it (really it'd be better to work against git master as that's > where this would need to be merged first, but it's probably easier for > you to test in your setup working from RELEASE/1.4 branch). > > Cheers, > Olly >