-
Notifications
You must be signed in to change notification settings - Fork 7
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
Allow gem to install h3 as a native extension #45
Conversation
328c2fc
to
3e6fd3b
Compare
dad1ce2
to
354aae8
Compare
6d9697e
to
9e4f929
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One of the benefits of FFI is not requiring a compiler :). But maybe in this case this proposal makes sense because the library does not seem to be packaged (apt
, brew
, etc.) and users need to compile H3 themselves anyway, right?
Would it be a way to retrieve the last stable version?
|
||
desc "Remove compiled H3 library" | ||
task :clean do | ||
File.delete("ext/h3/src/Makefile") if File.exists?("ext/h3/src/Makefile") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder... the Makefile
of H3 has a clean
target. It does not delete the directories themselves, but wouldn't it be enough to delegate to their make clean
and assume they know what it needs to be cleaned?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good thinking - I'll see if it works 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tried it - it doesn't seem to remove any of the compiled code...
@@ -8,7 +8,7 @@ def self.extended(base) | |||
base.extend FFI::Library | |||
base.include Structs | |||
base.include Types | |||
base.ffi_lib ["libh3", "libh3.1"] | |||
base.ffi_lib ["ext/h3/src/lib/libh3.dylib", "ext/h3/src/lib/libh3.so"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do these relative paths work when a user uses the gem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Tested it locally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI I tested this badly!
After releasing 3.3.0
I added it to stuart-api
and discovered a LoadError
. The paths do indeed need to be absolute 🤦♂️
Hotfixed here: StuartApp/h3_ruby@d192b41
I yanked 3.3.0
from Rubygems and released 3.3.1
. Seems to work just fine now 😅
Regarding packaging - no, there's no binary packages at all for H3 and the other bindings assume it isn't preinstalled so go about downloading/building it directly. |
Since we include it as a git submodule we can move HEAD to the correct place each time we release a new version. |
9e4f929
to
697bea9
Compare
Bit hacky, but it works.
Fixes #2 🎉