Then we could provide a small C dataset API somewhere in the C++ source
tree (perhaps `arrow/dataset/c/api.h`?). It would be
unstable/experimental and could undergo changes or even removal without
notice.
Regards
Antoine.
Le 23/08/2021 à 20:07, Matthew Topol a écrit :
Because go is always statically compiled for whatever platform you're on at the
time, the default behavior is for importing go libraries using `go get` from
the command line actually does a git clone of the code and compiles it on the
fly (because go's compiler is pretty darn fast) and caches statically compiled
versions of dependencies for builds. Go-Arrow follows this same typical golang
pattern that you don't distribute a shared object binary but rather the go tool
pulls the code and compiles the relevant code as needed. Because the import
path tells it the full path to the go.mod file (the top of the module) it knows
that it only needs the go/arrow directory tree for the module and as such it
doesn't clone the entire git repo.
-----Original Message-----
From: Antoine Pitrou <anto...@python.org>
Sent: Monday, August 23, 2021 2:00 PM
To: dev@arrow.apache.org
Subject: Re: [C++][Go] CGO For Dataset API Integration
Le 23/08/2021 à 19:53, Matthew Topol a écrit :
The only thing I don't like it being a private module in the Go implementation
is distribution. For native go code, consumers can just perform `go get` and
have it work. But for this interface, it would require both consumers of the
module and any consumers of those consumers to have a local built version of
this library locally when building their Go code. Easy to static link in for
distributing binaries, but not for library builders.
Hmm, I think I'm lacking some context. Do consumers of Go-Arrow code typically
recompile Go-Arrow instead of using an existing binary?
