-
-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Golang bindings and amalgamation support #92
Comments
Thank you very much, Riyaz! I hope sqlean will be of some use to you. The project is not intended to be amalgamaized. That would require globally unique symbol names, which makes them pretty ugly. But you don't need an amalgamation to compile
And here is how
As for the dangling |
The reason I went with amalgamation is to make the library With python, I guess since there's a pre-package step before distribution, its feasible to download, compile and link, and ship the resulting package, and hence, not require pre-processing / amalgamation. With golang, since there's no support for binary distribution, you'd need all the sources to be present during compilation. Thanks for your input 👍 I'll try and explore solutions that doesn't involve amalgamaized source 🙌 |
Sorry I wasn't much help. I tried to make the symbols globally unique earlier, but the code got so ugly that I dropped the idea. I may revisit it one day. If there is anything else I can do to make things easier for you, please let me know. I see that |
No worries! I found an alternative way by downloading and committing the source files from I'd still prefer managing a single amalgamated file vs. a bunch of spread out C files. Besides, I think amalgamation would be helpful in other languages and / or stack as well (like Besides that, all the efforts you've put in #84 makes building an amalgamation file really simple and straightforward. I understand a conscious effort like this would be required for every extension you add to the main set. Would love to hear your thoughts on this! |
I completely agree that a single amalgamated file would be great. I just haven't figured out how to implement it without making the code a mess. I should try again :) Thanks for the |
Hi 👋 First of all, thanks for this super amazing library and set of extensions! Great work 👏
Inspired
sqlean.py
and based on code and discussion under #69, #79, #82 and #84, I started out withsqlean.go
project to providego
bindings forsqlean
.There I'm generating an amalgamation build,
sqlean.c
, using the script undertools/amalgamate.go
.Following are a couple of issues I ran into when trying to build the amalgamated sources:
I get redefinition error for the symbol
utf8_lookup
. There seems to be two static global variables undersrc/fuzzy/translit.c
andsrc/unicode/extension.c
that share the same name.There's a random
#ifdef __cplusplus
insrc/unicode/extension.c
, presumably to close a priorextern "C" {
definition, without any matching opening clause. Caught this when skimming through the generated file. This might cause unexpected build failures under ac++
compiler.I'm also facing some difficulties compiling
src/regexp
(because ofpcre2
) but I think it can be overcome by laying out the amalgamation file more intelligently. I'll give it a shot and update.For now, to go ahead with what's working I've disabled
src/fuzzy
andsrc/regexp
.The text was updated successfully, but these errors were encountered: