Open yuchanns opened 2 days ago
Adding some context:
We have discussed similiar ideas in the past.
- Still requires
libopendal_c.so
. - We can embed it in go files for each platform_suffix file. eg: _linux.go, _windows.go,
From the ASF perspective, distributing binaries in source form is not permitted. Therefore, we might not include in this repo directly. Perhaps we could set up an additional repository for releases.
From the ASF perspective, distributing binaries in source form is not permitted.
I add a pros: Dynamic Inject distributing binaries. It can be an advantage as current features of bindings can not be controlled by users.
- Depends on preinstalled
libffi
. - libffi is widely used in many languages and commonly preinstalled on many platforms. You can easily install it with the package manager if not available.
Confirmed. libffi
is widely pre-installed and depended:
https://archlinux.org/packages/core/x86_64/libffi/
Looking forward to this!
Adding some context:
Ok, I've checked the context, and identified some major blockers:
go-import
doesn't support subdirectory.Well, these are truly obstacles. I've no idea how to resolve them.
TBH, I do think it is impossible to support subdirectories in the foreseeable future as the Go team prioritizes things based on their needs. Even if the problem has been resolved, we still have to challenge the binary distribution as Go is not designed to be extended with other languages.
IMO, it is inevitable to have multiple root repos for go bindings of various features. As long as these sources are distributed under opendal.apache.org/go
, users can trust them, and no need to care where are they placed.
As for the *.so
binaries, they can be loaded separately just like various dialects in gorm.io/driver/{sqlite,mysql,postgres}
.
That is to say:
package main
import (
opendal "opendal.apache.org/go"
_ "opendal.some.others/services/s3" // this dynamic inject *.so
)
I regret that these guideline-level issues have prevented the implementation of go-binding.
package main import ( opendal "opendal.apache.org/go" _ "opendal.some.others/services/s3" // this dynamic inject *.so )
Wow, I didn't know that was possible! I think we can start with github.com/apache/opendal/bindings/go
and your own "*.so" files to see how it functions. If it works well, I'm willing to help manage the artifacts by setting up a new repository called github.com/apache/opendal-go-artifacts
(just for example).
I think we can start with github.com/apache/opendal/bindings/go and your own "*.so" files to see how it functions.
Cool. I will take a try next week.
Hello community!
I'd like to introduce you to a native method for supporting Go bindings without CGO.
This capability primarily relies on two libraries: purego and libffi.
To support the passing and returning of structure values, we need to create lightweight Go libffi bindings by wrapping purego, which is already provided by ffi. We can either use it or maintain it ourselves directly.
Then we can call arbitrary C functions using libffi from Go without enabling CGO, which is why I refer to it as Native support!
Here's a POC that demonstrates its functionality with backend
memory
andaliyun_drive
: gopendal.Pros:
CGO
. - It is beneficial to promote opendal to various well-known pure Go basic libraries.libopendal_c.so
- Users can inject custom featured libs under their control.Cons:
libopendal_c.so
. - We can embed it in go files for each platform_suffix file. eg: _linux.go, _windows.go,libffi
. - libffi is widely used in many languages and commonly preinstalled on many platforms. You can easily install it with the package manager if not available.What do you think? I look forward to your comments!