go - Usando paquetes binarios directamente

Question

Estoy escribiendo una biblioteca en Go. Estoy planeando distribuirlo, y con el requisito principal de '' sin códigos fuente ''.

Para las pruebas, he creado dos espacios de trabajo como los siguientes,

WS1

• compartimiento/
• pkg / linux_amd64 / lib.a
• src / lib / src.go

WS2

• compartimiento/
• pkg /
• src / main / main.go

Mi primer espacio de trabajo (WS1) es la biblioteca ficticia real, que tiene algunas funciones de utilidad. El segundo espacio de trabajo (WS2) tiene una función principal que utiliza el paquete (lib.a) de WS1.

Todo funcionaba bien hasta que elimino las fuentes de WS1. Si elimino el directorio /lib/src.go en WS1, obtengo el siguiente error durante la compilación,

main.go: 5: 2: no puedo encontrar el paquete "lib" en cualquiera de: / usr / local / go / src / pkg / lib (desde $ GOROOT) ../Testing/ws1/src/lib (desde $ GOPATH)

El mensaje anterior nos indica que debemos mantener los archivos de origen también. Los paquetes binarios precompilados por sí solos no se pueden usar directamente .

Según algunas sugerencias en línea, podemos mantener algunas fuentes ficticias con un valor de marca de tiempo menor que la marca de tiempo de los paquetes binarios. Pero, esto no parece ser una solución factible para nosotros. ¿Qué sucede si la marca de tiempo de las fuentes ficticias se actualiza desafortunadamente?

He visto un problema similar discutido aquí, https://github.com/golang/go/issues/2775

Mis preguntas:

1. ¿Distribuir las fuentes es la única posibilidad en Golang?

2. ¿Por qué Go no proporciona una provisión para usar archivos ''.a'' directamente?

3. Si mantener la fuente es obligatorio para Go, ¿por qué esta pequeña cosa no se menciona en ninguna parte de Go? (o) ¿Me estoy perdiendo algo aquí?

¡Gracias de antemano por vuestra ayuda, chicos!

Answer 1

Los paquetes solo binarios estarán disponibles en go1.7 (agosto de 2016) - https://tip.golang.org/doc/go1.7

Esta versión agrega soporte experimental y mínimo para la creación de programas utilizando paquetes de solo binarios, paquetes distribuidos en forma binaria sin el código fuente correspondiente. Esta función es necesaria en algunas configuraciones comerciales, pero no está diseñada para integrarse completamente en el resto de la cadena de herramientas. Por ejemplo, las herramientas que asumen el acceso para completar el código fuente no funcionarán con dichos paquetes, y no hay planes para admitir dichos paquetes en el comando "ir a buscar".

La propuesta se encuentra en https://github.com/golang/proposal/blob/master/design/2775-binary-only-packages.md , https://tip.golang.org/pkg/go/build/#hdr-Binary_Only_Packages tiene más información sobre la nueva característica.

Answer 2

Los paquetes solo binarios son compatibles con go 1.7 ahora.

Solo puede proporcionar archivos .a y archivos falsos sin el código fuente para distribuirlo ahora.

Aquí hay un ejemplo detallado y un script del generador de paquetes binarios Go1.7.

myframework / frameImplement.go

package myframework

import "fmt"

func Hello(name string) string {
    return fmt.Sprintf("Hello, %s!", name)
}

main / 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"))
}

Si quiero ocultar el código fuente de mi framework, solo compile con go build -i -o $GOPATH/pkg/framework.a , luego modifique su código fuente para

//go:binary-only-package

package framework

//you can add function prototype here for go doc etc, but no necessary.

, en el que puedes usar mi generador de paquetes binarios (script) para ayudarte.

Answer 3

El compilador Go solo necesita los archivos .a . Si los envía, cualquiera podrá usar su paquete sin el código fuente.

PERO sus usuarios tendrán que invocar el compilador (por ejemplo, 6g , no la herramienta para go ) manualmente. Si envía un archivo myfoo.a y una fuente ficticia myfoo.go contiene solo el package myfoo y la marca de tiempo de myfoo.a es más nueva que la de myfoo.go (y coloca todo en su lugar), puede usar la herramienta go .

Actualización : la versión más reciente de la herramienta go detecta los archivos eliminados y requiere todos los archivos (posiblemente vacíos) con los nombres de archivo adecuados y las marcas de tiempo más antiguas en la carpeta src. La gestión de una marca de tiempo no debe ser un factor de ruptura.

No se deje engañar de que go Tool es Go: es una herramienta muy conveniente para compilar, probar y obtener, cualquiera que sea su código Go, pero no es el idioma ni el compilador ni el enlazador.

BTW: Realmente no tiene sentido no distribuir las fuentes.