Thanks Tim, but my goal is to make things transparent and easy to the users
of my libraries. So I don't want to force them to run Makefiles (in my case
large Bazel builds for one project, Makefile for the other), install
C++/Rust build tools, deal with dockers, etc. Ideally, `go get` would just
take care of everything. If that is not possible, I'm wondering what is the
easiest next thing.
The reasoning is that a largish project often depends on dozens of
libraries, if we need to do this kind of stuff for every library, its too
much friction. Go tools are awesome ('go get' works so well for me) when
there are no CGO dependencies ... alas, not everything is implemented in Go.
Indeed, pre-built binaries is platform dependent -- and requires separate
files/tgz per architecture, as you point out. How to have these
dependencies installed, and picked up by go compiler automatically (setting
up of CGO's CFLAG, LDFLAG LD_LIBRARY_PATH, etc), and be removed if no
longer used ? With minimum user headache/work...
cheers
Jan
On Thursday, October 12, 2023 at 3:16:58 AM UTC+2 Tim Casey wrote:
>
>
> 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.so...@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...@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/a5feedde-9a18-4b29-92a0-6f76d96f01c4n%40googlegroups.com.
