I would put down Makefile includes for the supported targets and build each target at a time, as cross compiled shared libraries. This is easier for linux, harder for windows. But, you can build/export from docker containers as part of the overall build process to allow simulated build environments. At some point, you may come to a dependency in which you have to build the included C code for it to run in platform dependent libraries. At this point, you probably will want to build on the environment as you go. You can cross target *.o, but build the *.so on the specific target.
You could have separate repos and distribute the C code from a dependency point of view. This would be a tgz of 'shared/$ARCH/$COMPILED_LIB", or some such. On Wed, Oct 11, 2023 at 5:29 PM Richard Wilkes <raw.softw...@gmail.com> wrote: > It isn't a great solution, but I currently include the built library files > and necessary headers in the git repo alongside the Go code. You can see an > example here > https://github.com/richardwilkes/unison/tree/main/internal/skia where I > include the skia library I built for use in my UI framework, unison. > > The main downside of this is bloating the git repo with the binary .a and > .dll files... but I've not found a better way to handle it. glfw, which > unison also depends upon, does something very similar. > > - Rich > > On Wednesday, October 11, 2023 at 2:58:23 AM UTC-7 Jan wrote: > >> hi, >> >> I'm developing a couple of ML framework/libraries for Go that depend on >> C/C++ code. Once C-libraries dependencies are installed, the CGO >> integration work great. >> >> Now, for end-users that just want to use these Go libraries, having to >> figure out how to manually build and install those C/C++/Rust dependencies >> is a hassle -- sadly each one with a different type of build system. >> >> I offer pre-built `.tgz` files (for a limited set of architectures) with >> the required `.h` and `.a/.so` files along the releases, which facilitates. >> But it's still a hassle to install -- and no auto-uninstall if someone is >> no longer using the Go module. >> >> I was wondering if others have figured out how to handle this in a nicer >> way. Is there a recommended way to distribute prebuilt CGO dependencies ? >> >> I like how Python wheels (`.whl` files) solve the issue, by including the >> pre-built libraries in a sub-directory of the python library installation. >> I was hoping there would be a similar way (maybe with a separate tool) to >> integrate with `go.mod`. >> >> Any pointers, thoughts or suggestions are very appreciated. >> >> Thanks! >> Jan >> >> ps: While searching I saw similar questions, but none that exactly >> answered this aspect of distribution. Just in case, apologies if it's a >> duplicate question. >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/3b03b9e1-655e-452a-9b97-e9471b9b9dc1n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/3b03b9e1-655e-452a-9b97-e9471b9b9dc1n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAMyFqkRai48nKKFvqPN1ALU0LipzTgJe0YEPFmqx1Dv0T9RkTA%40mail.gmail.com.
