flatpak
Add support for external dir hasher
Allows providing hash-cmd. Protocol is that cmd will be executed and output will be used to calculate dir checksum. If program fails - it falls back to rebuilding.
@alexlarsson Mind to have a look? Seems like you said that checksumming dir was "not possible". Not sure what you meant.
Can you give some real world examples of hash commands for an entire directory?
Also it is very common that a project uses a flatpak build dir inside of the same directory, which is impossible to say nothing changes, so maybe there should be a check for that.
Can you give some real world examples of hash commands for an entire directory?
Also it is very common that a project uses a flatpak build dir inside of the same directory, which is impossible to say nothing changes, so maybe there should be a check for that.
I have most current experience with both Rust and Go. For both "a project uses a flatpak build dir inside of the same directory" is NOT an issue because they have either a very strict standard layout or mostly people adhere to best practices.
Thus the real world example for e.g. Golang would be:
build-options:
env:
GOBIN: /app/bin
GOROOT: /usr/lib/sdk/golang
modules:
- name: foo
buildsystem: simple
sources:
- type: dir
path: .
hash-cmd: [go run ./cmd/dirhash cmd internal go.mod go.sum]
build-commands: [
"$GOROOT/bin/go build -C ./cmd/app -o foo",
"install -Dm00755 gadget-app $FLATPAK_DEST/bin/foo",
]
dirhash here is a recursive hash program.
Following best-practices in Go, source can be found in directories cmd, internal and pkg only. Also the only files in the root can be go.*. Note also that you do not need to handle vendor directory since it is a direct consequence of go.sum.
The general question though is whether it would not be better to have a hash for every build-command...
I don't think it should be per build-command. It is a departure from how f-b operates. Build commands aren't necessarily reproducible.