Использование двоичных пакетов напрямую

Я пишу библиотеку в 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).