PaiGack/moon_shadow/buildinfo

PaiGack/moon_shadow/buildinfo does not have a README file

BuildInfo

pub(all) struct BuildInfo {
  moon_version : String
  moonc_version : String
  profile : String
  target : String
  debug : String
  release : String
} derive(Eq, @moonbitlang/core/debug.Debug
Debug)

The toolchain that compiled this application, plus the variant it was compiled in.

Every field is a string: it ends up in --version output or a log line, and nothing here is worth formatting twice. debug and release are the profile as a marker — one of them is "", so the struct can be read the way --version output usually is: append whatever is non-empty.

BuildInfo::equal

source

#deprecated("`BuildInfo::equal` is deprecated, use `Eq::equal` instead.")
fn BuildInfo::equal(BuildInfo, BuildInfo) -> Bool

BuildInfo::from_toolchain

source

fn BuildInfo::from_toolchain(toolchain : ToolchainInfo) -> BuildInfo

The application's own answers — profile and backend — plus the toolchain the generator captured.

The join: gen knows the toolchain and writes it into the virtual package implementation, this package knows the profile and backend because they are targets-selected files, and neither can see the other's half. Keeping the join in one function means the struct literal appears once, not twice.

BuildInfo::moon

source

fn BuildInfo::moon(self : BuildInfo) -> String

moon 0.1.20261020, "" when the generator could not read it.

BuildInfo::moonc

source

fn BuildInfo::moonc(self : BuildInfo) -> String

moonc v0.10.16+b1a0e846e, "" when the generator could not read it.

BuildInfo::not_equal

source

#deprecated("`BuildInfo::not_equal` is deprecated, use `Eq::not_equal` instead.")
fn BuildInfo::not_equal(x : BuildInfo, y : BuildInfo) -> Bool

BuildInfo::to_repr

source

#deprecated("`BuildInfo::to_repr` is deprecated, use `@moonbitlang/core/debug.Debug::to_repr` instead.")
fn BuildInfo::to_repr(BuildInfo) -> @moonbitlang/core/debug.Repr
Repr

ToolchainInfo

source

pub(all) struct ToolchainInfo {
  moon_version : String
  moonc_version : String
} derive(Eq, @moonbitlang/core/debug.Debug
Debug)

moon and moonc as reported by moon version --all when the generator ran.

A struct rather than a (String, String) tuple: a later field (channel, host, build date) is then an additive change instead of a breaking one, and the name says what the pair belonged to. The generator writes a value of this type into the virtual package implementation, and BuildInfo::from_toolchain turns that value into the whole picture of the build.

ToolchainInfo::empty

source

fn ToolchainInfo::empty() -> ToolchainInfo

ToolchainInfo::equal

source

#deprecated("`ToolchainInfo::equal` is deprecated, use `Eq::equal` instead.")
fn ToolchainInfo::equal(ToolchainInfo, ToolchainInfo) -> Bool

ToolchainInfo::moon

source

fn ToolchainInfo::moon(self : ToolchainInfo) -> String

moon 0.1.20261020, "" when the generator could not read it.

ToolchainInfo::moonc

source

fn ToolchainInfo::moonc(self : ToolchainInfo) -> String

moonc v0.10.16+b1a0e846e, "" when the generator could not read it.

ToolchainInfo::not_equal

source

#deprecated("`ToolchainInfo::not_equal` is deprecated, use `Eq::not_equal` instead.")
fn ToolchainInfo::not_equal(x : ToolchainInfo, y : ToolchainInfo) -> Bool

ToolchainInfo::to_repr

source

#deprecated("`ToolchainInfo::to_repr` is deprecated, use `@moonbitlang/core/debug.Debug::to_repr` instead.")
fn ToolchainInfo::to_repr(ToolchainInfo) -> @moonbitlang/core/debug.Repr
Repr

render_build_info

source

fn render_build_info(info : ToolchainInfo, pkg_path~ : String) -> String

The build_info() implementation: what the generator writes into a virtual package implementation, and what this package's own shadow/generated.mbt already contains.

One function, not two fields: the implementation hands back a BuildInfo and BuildInfo::from_toolchain in this package attaches the profile and the backend to it. Both sides are compiled for the same target with the same profile — they are packages of one application — so the profile is asked for once, at the place that can also see it, rather than sent across the boundary as two more strings.

Deterministic, so regenerating from the same toolchain yields no diff.

pkg_path is the full package path of buildinfo, the way the hand written pkg.mbti of an implementation spells it. See mooninfo's renderer.