It is cleaner to have this happen outside of the gok tool.
That way, users can see the config, as the tool will read it,
using `cat config.json` before calling gok.
related to https://github.com/golang/go/issues/53804
When validation fails, the error message looks like this:
2022/09/17 20:53:07 /tmp/gokrazy-bins-1604202262/dhcp4d is not an ELF binary!
bad magic number '[0 0 0 0]' in record at byte 0x0
Before
Before this commit, gokr-packer was building all Go binaries to include in the
gokrazy root file system from the same working directory, meaning the same
go.mod and go.sum files were used for all packages.
This wasn’t really an intentional choice, instead it was the easiest way to get
things working when Go switched from GOPATH to modules.
The downside of that approach is that updates in one package can result in other
packages no longer building. In the most extreme cases, it can mean that two
packages cannot be built into the same gokrazy root file system at all.
After
With this commit, gokr-packer will build each package in a subdirectory of the
new builddir/ directory in your gokrazy instance directory,
e.g. ~/gokrazy/scan2drive/builddir.
If there is no go.mod file in the builddir yet, gokr-packer will copy the
top-level go.mod/go.sum files into the builddir to keep your current module
selection, and hopefully build exactly the same binary as before.
Influencing the granularity
Often, one Go package will be the only package you use from a certain Go
module. But this isn’t always the case: for example, the system packages
github.com/gokrazy/gokrazy/cmd/dhcp and github.com/gokrazy/gokrazy/cmd/ntp both
come from the github.com/gokrazy/gokrazy module.
gokr-packer will by default create a separate builddir, including a separate
go.mod and go.sum, for each package, even when they come from the same module.
If you want to add module-wide replace directives to your go.mod file,
you can influence the granularity at which gokr-packer works as follows.
Move the go.mod/go.sum files to the directory level within the builddir/
hierarchy at which you would like to work. gokr-packer will look for
go.mod/go.sum files at the package level, going one level up until it finds the
files.
Hence, you can use the following locations, ordered from finest to coarsest
granularity:
1. per-package builddir (default), e.g.:
builddir/github.com/gokrazy/gokrazy/cmd/dhcp/go.mod
2. per-module builddir (convenient when working with replace directives), e.g.:
builddir/github.com/gokrazy/gokrazy/go.mod
3. per-org builddir (convenient for wide-reaching replace directives), e.g.:
builddir/github.com/gokrazy/go.mod
4. single builddir, preserving the previous behavior, e.g.:
builddir/go.mod
related to https://github.com/gokrazy/tools/issues/38
The GOFLAGS handling is the opposite of how the Go tool handles it, where
GOFLAGS provides default values that the command line then overwrites. I think
it’s better to match that behavior.
Instead, allow extending gokr-packer’s list of build tags via the buildtags/
per-package config directive.
Also, add osusergo and netgo build tags by default so that even when cgo is
enabled, gokrazy code results in statically linked binaries.
related to https://github.com/stapelberg/scan2drive/issues/18
This offers a way to get around Go package zip file restrictions,
such as:
• executable modes are lost in a Go package zip file
• files that only differ in casing can’t be stored in a Go package zip file
fixes https://github.com/gokrazy/tools/issues/32
This alias resolves to ttyAMA0 currently, but will be rewritten by the Raspberry
Pi firmware to resolve to ttyS0 once we drop our custom dtb patches.
related to https://github.com/gokrazy/gokrazy/issues/49
The currently valid values are:
-serial_console=UART0 (see next option)
-serial_console=ttyAMA0,115200 (for example)
-serial_console=disabled (serial available for userspace)
-serial_console=off (serial turned off)
related to https://github.com/gokrazy/gokrazy/issues/49
