Documentation
¶
Overview ¶
Package target is the single source of truth for the *target* platform/arch of a build.
brewkit is historically a *native* build tool: everything pivots on the host == the machine it runs on == the thing it builds for. To cross-compile (notably Windows PE bottles built on a linux/darwin host) we split "where am I running" (Host) from "what am I building for" (Target). Only OUTPUT/target decisions consult Target:
- the `if:` guards in a recipe's build/test script
- platform-keyed env selection
- fix-up (POSIX relocation) selection
- the bottle slug (platform-key)
Shell-environment decisions ("which TMPDIR does *this* host use") keep using Host. The target is taken from (first match wins):
- the BREWKIT_TARGET env var (eg. "windows/x86-64" or "windows+x86-64")
- Host() (native build — byte-for-byte unchanged behaviour)
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func IsArch ¶
IsArch reports whether s is an architecture this factory builds for, in pkgx's spelling (`x86-64`, not `amd64` — see pkgxArch).
func IsPlatform ¶
Host is the platform/arch/triple of the machine bk is running on. IsPlatform and IsArch are the ONE vocabulary of platform names.
There were two. buildscript kept its own `platforms`/`arches` maps to decide what a recipe's `env: {aarch64: …}` key and its `if: linux/x86-64` guard mean, and when s390x was added here that copy was not. The consequences were silent in both directions: an `env` keyed by s390x became a literal variable of that name, and a step guarded `if: s390x` ran on EVERY platform, because matchGuard lets an unrecognised condition through rather than dropping the step.
Predicates rather than the maps, so a caller cannot hold a reference and drift again.
Types ¶
type Target ¶
type Target struct {
Platform string // darwin | linux | windows
Arch string // x86-64 | aarch64 | s390x
// Triple is the compiler triple — and for every target but windows it is
// the triple of the machine bk RUNS ON, not the one named here.
//
// $ BREWKIT_TARGET=linux/s390x bk target # on a Mac
// linux/s390x triple=aarch64-apple-darwin cross=true
//
// That is correct today and reads as a bug, which is why it is written
// down rather than left to be rediscovered. bk cross-compiles to windows
// and nowhere else: a unix target is always built natively or under
// emulation, so host and target coincide and the value is right. The
// windows branch of Resolve computes a real cross triple because windows
// is the case where they differ.
//
// It matters because the value does not stay here. It names the compiler
// shims autoconf probes for, and it reaches every recipe as {{hw.target}}
// — a name that promises the target. A recipe author reading that name
// will believe it, and one of ours did: rust-lang.org/cargo picks its
// bootstrap archive by this triple, which is right only while the two
// coincide, and the comment there says so.
//
// A unix→unix cross build would need this computed from Platform/Arch.
// Changing it before then is a fix to a case that cannot arise, and the
// test below pins the current answer deliberately.
Triple string
}
Target is the resolved build target.