Utilizzo di pacchetti binari direttamente

Question

Sto scrivendo una libreria in Go. Sto pianificando di distribuirlo e con un requisito principale di "senza codici sorgente".

Per il test, ho creato due aree di lavoro, come segue,

WS1

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

WS2

• bin/
• pkg/
• src/main/main.go

Il mio primo lavoro (WS1) è la libreria manichino vero e proprio, che ha alcune funzioni di utilità. Second workspace (WS2) ha una funzione principale che utilizza il pacchetto (lib.a) di WS1.

Tutto funzionava correttamente finché non rimuovo i sorgenti da WS1. Se rimuovo il /lib/src.go directory in WS1, sto ottenendo il seguente errore durante il movimento di generazione,

main.go: 5: 2: non riesce a trovare il pacchetto "lib" in uno qualsiasi dei: /usr/local/go/src/pkg/lib (da $ GOROOT) ../Testing/ws1/src/lib (da $ GOPATH)

il messaggio sopra di noi indica che dovremmo tenere la fonte file pure. I pacchetti binari precompilati da soli non possono essere utilizzati direttamente.

Sulla base di alcuni suggerimenti online, è possibile che alcune fonti fittizie con valore di timestamp inferiore al timestamp dei pacchetti binari. Ma questo non sembra essere una soluzione fattibile per noi. Cosa succede se il timestamp delle sorgenti fittizie è stato aggiornato purtroppo?

ho visto problema simile discusso qui, https://github.com/golang/go/issues/2775

Le mie domande:

1. distribuire le fonti è l'unica possibilità in Golang?

2. Perché Go non fornisce una disposizione per l'utilizzo diretto dei file ".a"?

3. Se mantenere la sorgente è obbligatorio per Go, perché questa piccola cosa è non menzionata ovunque in Go? (o) Mi manca qualcosa qui?

Grazie in anticipo per il vostro aiuto ragazzi!

Answer 1

Il compilatore Go ha solo bisogno dei file .a. Se li spedisci, chiunque sarà in grado di utilizzare il pacchetto senza il codice sorgente.

MA gli utenti dovranno richiamare il compilatore (ad esempio 6g, non lo strumento go) manualmente. Se spedite un file myfoo.ae una fonte fittizia myfoo.go contenente solo package myfoo e il timestamp del myfoo.a è più recente di quella di myfoo.go (e si mette tutto a posto) è possibile utilizzare lo strumento go.

Aggiornamento: la versione più recente dello strumento go rileva i file eliminati e richiede tutti i file (eventualmente vuoti) con i nomi file corretti e i timestamp precedenti nella cartella src. La gestione di un timestamp non dovrebbe essere un dealbreaker.

non fatevi ingannare che lo strumento go è Go: E 'un comodo strumento morti per costruire, testare, ottenere, qualunque sia il vostro codice di Go, ma non è né la lingua né il compilatore né il linker.

BTW: Non c'è davvero alcun senso nel non distribuire le fonti.

Answer 2

I pacchetti binari saranno disponibili in go1.7 (agosto 2016) - https://tip.golang.org/doc/go1.7

Questo rilascio aggiunge sperimentale, supporto minimo programmi di costruzione utilizzando pacchetti binari, pacchetti distribuiti in forma binaria senza il codice sorgente corrispondente. Questa funzione è necessaria in alcune impostazioni commerciali, ma non è pensata per essere completamente integrata nel resto della toolchain. Ad esempio, gli strumenti che presuppongono l'accesso a un codice sorgente completo non funzioneranno con tali pacchetti e non ci sono piani per supportare tali pacchetti nel comando "go get".

La proposta è a https://github.com/golang/proposal/blob/master/design/2775-binary-only-packages.md, https://tip.golang.org/pkg/go/build/#hdr-Binary_Only_Packages ha ulteriori informazioni sulla nuova funzione.

Answer 3

I pacchetti solo binari sono supportati in go 1.7 ora.

È possibile fornire solo file .a e file di go fake senza codice sorgente per distribuirlo ora.

Ecco un detailed example and a script of Go1.7 binary package generator.

myframework/frameImplement.go

package myframework 

import "fmt" 

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

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

Se voglio nascondere il codice sorgente del framework, basta costruire con go build -i -o $GOPATH/pkg/framework.a, quindi modifica il codice sorgente in

//go:binary-only-package 

package framework 

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

, che è possibile utilizzare il mio generatore di pacchetti binari (script) per aiutarvi.