That's precisely what I was suggesting and expecting. Sounds good. I'll clean up my POC and make a proper PR sometime soon.
Thanks much for the discussion! --Matt -----Original Message----- From: Antoine Pitrou <anto...@python.org> Sent: Monday, August 23, 2021 2:18 PM To: dev@arrow.apache.org Subject: Re: [C++][Go] CGO For Dataset API Integration 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? >
