Использование двоичных пакетов напрямую
Я пишу библиотеку в Go. Я планирую распространять его и с основным требованием " без исходных кодов".
Для тестирования я создал две рабочие области, такие как следующие,
WS1
- бен /
- упак /linux _amd64/lib.a
- src/lib/src.go
WS2
- бен /
- упак /
- SRC/Основной/main.go
Моя первая рабочая область (WS1) - это фактическая фиктивная библиотека, которая имеет некоторые служебные функции. Вторая рабочая область (WS2) имеет основную функцию, которая использует пакет (lib.a) из WS1.
Все работало хорошо, пока я не удалю источники из WS1. Если я удалю каталог /lib/src.go в WS1, я получаю следующую ошибку во время сборки go,
main.go: 5: 2: не удается найти пакет "lib" в любом из: /usr/local/go/src/pkg/lib (из $GOROOT)../Testing/ws1/src/lib (из $GOPATH)
В приведенном выше сообщении указывается, что мы также должны хранить исходные файлы. Предварительно скомпилированные бинарные пакеты не могут использоваться напрямую.
Основываясь на нескольких предложениях в Интернете, мы можем сохранить некоторые фиктивные источники с меткой времени меньше, чем временная метка бинарных пакетов. Но это не представляется возможным для нас. Что произойдет, если временная отметка фиктивных источников будет обновлена, к сожалению?
Я видел подобную проблему, обсуждаемую здесь,
https://github.com/golang/go/issues/2775
Мои вопросы:
-
Распространение источников - единственная возможность в Голанге?
-
Почему Go не предоставляет условие для непосредственного использования файлов .a?
-
Если сохранение источника является обязательным для Go, почему эта маленькая вещь
не упоминается нигде в Go? (или) Я что-то пропустил здесь?
Заранее благодарю вас за помощь!
Ответы
Ответ 1
Компилятор Go просто нуждается в файлах .a
. Если вы отправляете их, кто-то сможет использовать ваш пакет без исходного кода.
НО ваши пользователи должны будут вручную вызвать компилятор (например, 6g
, а не инструмент go
). Если вы отправляете файл myfoo.a
и фиктивный источник myfoo.go
, содержащий только package myfoo
, а метка времени myfoo.a
является более новой, чем метка myfoo.go
(и вы помещаете все на место), вы можете использовать go
инструмент.
Обновить. Более новая версия инструмента go обнаруживает удаленные файлы и требует наличия всех файлов (возможно, пустых) с соответствующими именами файлов и более старыми метками времени в папке src.
Управление меткой времени не должно быть разбойником.
Не обманывайте себя, что инструмент go
- это Go: это удобный инструмент для сборки, тестирования, получения, независимо от вашего кода Go, но он не является ни языком, ни компилятором, ни компоновщиком.
BTW: Нет смысла не распространять источники.
Ответ 2
Бинарные пакеты будут доступны в go1.7 (август 2016 г.) - https://tip.golang.org/doc/go1.7
Этот выпуск добавляет экспериментальную минимальную поддержку для создания программ с использованием только двоичных пакетов, пакетов, распределенных в двоичной форме без соответствующего исходного кода. Эта функция необходима в некоторых коммерческих настройках, но не предназначена для полной интеграции в остальную часть инструментальной цепочки. Например, инструменты, предполагающие доступ к полному исходному коду, не будут работать с такими пакетами, и нет планов поддерживать такие пакеты в команде "get get".
Предложение находится в https://github.com/golang/proposal/blob/master/design/2775-binary-only-packages.md, https://tip.golang.org/pkg/go/build/#hdr-Binary_Only_Packages имеет дополнительную информацию о новой функции.
Ответ 3
Теперь пакеты с бинарным пакетом поддерживаются в версии 1.7.
Вы можете предоставить файлы .a и поддельные файлы без исходного кода, чтобы распространять его сейчас.
Вот подробный пример и script генератора двоичных пакетов Go1.7.
myframework/frameImplement.go
package myframework
import "fmt"
func Hello(name string) string {
return fmt.Sprintf("Hello, %s!", name)
}
Основной/main.go
package main
import (
"fmt"
"golang-binary-package-generator/myframework"
)
func main() {
fmt.Println(" start program ")
fmt.Println(" print program :", myframework.Hello("print something now"))
}
Если я хочу скрыть исходный код рамки, просто создайте его с помощью go build -i -o $GOPATH/pkg/framework.a
, а затем измените исходный код на
//go:binary-only-package
package framework
//you can add function prototype here for go doc etc, but no necessary.
который вы можете использовать для создания моего генератора двоичных пакетов (script).