У меня есть пакет Go - назовите его foo
- я построил на основе существующего кода C и пытаюсь определить, как лучше его распространить.
Немного фона ... Вот упрощенная версия моей структуры каталогов:
foo/
|_ include/
|_ <several other header files>
|_ libs/
|_ <several .so files>
|_ foo.c
|_ foo.h
|_ foo.go
Урезанная голова foo.go
package foo
// #cgo CFLAGS: -I${SRCDIR}/include
// #cgo LDFLAGS: ${SRCDIR}/_foo.so -L${SRCDIR}/libs
// #include <stdlib.h>
// #include "foo.h"
import "C"
...
Где _foo.so
- это динамическая c lib генерируется как часть процесса сборки. Я могу нормально запускать и тестировать свой код, но я хочу иметь возможность распространять его и использовать в отдельном проекте, который использует go mod
. Здесь все становится немного сложнее, и мое понимание Go становится слабым. Концептуально, я просто хочу иметь возможность распространять каталог foo/
(.so
файлы и все) в месте, где другое приложение может найти и импортировать его, однако есть несколько камней преткновения, с которыми я столкнулся:
- Я не могу сделать это бинарным пакетом, так как мы находимся на Go 1.13 и, насколько я понимаю, эта возможность была отброшена после 1.12.
- Процесс сборки для Файл
.so
довольно существенный, и я не хочу, чтобы другие разработчики тратили 30 минут на создание этого объекта.
Я нашел много CGO демонстраций и блоги, но не много объяснений о том, как распространять CGO пакетов. Есть идеи?
Стоит отметить, что это для моей компании, где среда стандартная, поэтому мне не нужно контролировать разные ОС, и т. Д. c.
Редактировать
Я забыл упомянуть, что пытался вставить библиотеку в GOPATH
образа Docker и просто построить из этой базы микросервис, который зависит от него. Однако при создании службы с -mod=vendor
она не может найти библиотеку в GOPATH
:
RUN GOOS=linux \
GOARCH=amd64 \
CGO_ENABLED=1 \
GOFLAGS=-mod=vendor \
GO111MODULE=on \
go build \
-o service ./cmd/serve/main.go
./service
# build foo: cannot load foo: open /.../svc/vendor/foo: no such file or directory