Sergio
a65910298a
aerc b3:a33dbafdcc302154888095b7b5b14278461e60a69c4c8f310e388ba85f544d0a (43 ficheros) syncthing b3:544ebf125c682c720b8555faf4259cd48bee5b4a302c4a4cc29a7311691a6e34 Las dos necesitaron salirse del driver Go genérico, y por motivos distintos: - aerc se construye con SU GNUmakefile. El driver hace `go install` y deja el binario en /out/usr/bin; eso habría dado un paquete que ARRANCA Y NO SIRVE — aerc busca plantillas, stylesets y filtros en /usr/share/aerc, y dos filtros (colorize, wrap) son fuente C que hay que compilar. Con el Makefile el artefacto trae los 43 ficheros. VERSION y GOFLAGS van fijados a mano: el Makefile los saca de `git describe` y de contrib/goflags.sh, y el árbol llega al sandbox SIN .git ⇒ el binario dependería de si hay un .git al lado. - syncthing falla con `go install` a secas y el error no dice por qué: `lib/api/api_statics.go:45:25: undefined: auto.Assets`. La GUI web se sirve desde un fichero Go GENERADO que empaqueta gui/ y el repo no lo versiona: lo produce `go run build.go assets`. No es una dependencia que falte, es un CODEGEN. Todo local, sin red. commit = el tag PELADO en los dos casos (ambos son tags anotados; la trampa de foot).
46 lines
2.6 KiB
TOML
46 lines
2.6 KiB
TOML
# syncthing 2.1.5 — sincronización de ficheros entre máquinas, continua y sin servidor central.
|
|
# Un binario Go estático: no arrastra sonames, así que corre en la imagen sin el sysroot del lab
|
|
# debajo (misma forma que `caddy`, y por la misma razón).
|
|
#
|
|
# ── POR QUÉ ENTRA ──────────────────────────────────────────────────────────────────────────────
|
|
# El corpus tiene `rclone` y `restic` —copiar a un remoto y respaldar— pero nada que mantenga dos
|
|
# máquinas al día en ambos sentidos. Es el hueco entre «tengo una copia» y «trabajo en las dos».
|
|
#
|
|
# ⚠ EL `commit` ES EL TAG PELADO, NO EL OBJETO DE TAG. `v2.1.5` es un tag ANOTADO: su sha
|
|
# (3a67fe3a…) nombra el objeto de tag, no el árbol. Éste es el `^{}`. Misma trampa que `foot`.
|
|
#
|
|
# ⚠ VERSIÓN EN EL BINARIO: upstream la inyecta con `-ldflags -X` desde su `build.go`. El driver Go
|
|
# de takana hace `go install` genérico, así que `syncthing --version` dirá `unknown-dev`. Es
|
|
# cosmético y NO afecta al protocolo, pero conviene saberlo antes de diagnosticar con él.
|
|
name = "syncthing"
|
|
version = "2.1.5"
|
|
license = "MPL-2.0"
|
|
|
|
[source]
|
|
repo = "https://github.com/syncthing/syncthing"
|
|
commit = "2ca95cf1498104113fdfde46df4107f2450a0f71"
|
|
|
|
[build]
|
|
compiler = "zig-cc"
|
|
target = "x86_64-linux-musl"
|
|
link = "static"
|
|
# Sin `flags`: la fase de abajo nombra el paquete a mano, así que el autodetector de `main` no
|
|
# interviene. El árbol trae cuatro (cmd/syncthing, cmd/stdiscosrv, cmd/strelaysrv, cmd/ursrv) y que
|
|
# la elección dependa de una heurística es lo que no se quiere en una entrada de hash.
|
|
|
|
# ⚠ `go install ./cmd/syncthing` A SECAS NO CONSTRUYE, y el error no dice por qué:
|
|
# `lib/api/api_statics.go:45:25: undefined: auto.Assets`. La GUI web de syncthing se sirve desde un
|
|
# fichero Go GENERADO (`lib/api/auto/gui.files.go`) que empaqueta el árbol `gui/`, y el repo NO lo
|
|
# versiona: lo produce `go run build.go assets`. O sea que el paso que falta no es una dependencia
|
|
# sino un CODEGEN, y sin él el paquete `auto` existe pero está vacío. Todo local: `gui/` viene en el
|
|
# árbol, no hay red de por medio.
|
|
[build.phases]
|
|
compile = '''export GOCACHE=/src/.gocache GOTMPDIR=/src/.gotmp GOPATH=/tmp/gopath GOTOOLCHAIN=local CGO_ENABLED=0 GOFLAGS=-mod=vendor GOPROXY=off GOBIN=/out/usr/bin
|
|
mkdir -p /src/.gotmp
|
|
go run build.go assets
|
|
go install -trimpath -ldflags=-buildid= ./cmd/syncthing'''
|
|
|
|
# `go` es herramienta de BUILD: el binario sale autocontenido.
|
|
[deps]
|
|
build = ["go"]
|