nix/nixgen has the package and the clippy and nextest checks (in the default check sets), from a
"nixgen" platform of nix/workspace-src.nix that is the tool alone; it is a stub in every other
platform's source, so an edit of it rebuilds none of theirs.
nix/recorder holds the native packages and checks of macOS and Linux (the recorder and the
sources it indexes are the "recorder" platform of nix/workspace-src.nix), the Windows
build has it as one of its members, and the dev shell gets ffmpeg, resvg and GStreamer. The
flake inputs komorebi-mac and komorebi-windows are gone: the sources are in the tree.
Every platform module now defines its checks as allChecks.<name> and the new
nix/checks.nix says which set each is in (fmt, deny, windows-lint, windows-test,
linux-lint, linux-test, linux-options, macos-lint, macos-test, macos-options,
linux-demo, linux-nixos-eval, vm-fast, vm-slow; the vm tiers come from the
suites). A check in no set, or in two, fails the evaluation. checks.<system>
holds the members of the sets that are not heavy, the same split flake-one made
(vm-*, the Plasma guests, the module scenarios and run-kde left out), and the
placeholder legacyPackages.<system>.heavyChecks is gone: every set is one
linkFarm derivation, legacyPackages.<system>.checkSets.<set>, and its members
are legacyPackages.<system>.checkMembers.<set>.<name>. legacyPackages.<system>.vm
is unchanged.
The linux module is mostly reindented (the split wrapper is gone); no check
changed. Verified: see the revision that composes the sets.
treefmt and pre-commit, which the treefmt-nix and git-hooks-nix modules add to checks themselves, are allChecks of nix/common.nix now (those modules' own entries are switched off, treefmt.flakeCheck and pre-commit.check.enable), so that they are members of the set fmt.
One flake.nix and one flake.lock replace the root flake that re-exported two nested flakes.
The inputs are one nixpkgs (the revision the KDE flake was locked to, f05535a0: the VM suites
run against its Plasma and KWin 6.8.2), one crane, rust-overlay (19ecdd08, rustc 1.99.1),
flake-parts, treefmt-nix and git-hooks-nix, all the KDE flake revisions, plus asc. A second
nixpkgs, nixpkgs-x86_64-darwin (16c7794d, the macOS flake pin), serves the x86_64-darwin
outputs only: evaluating that system with the unified pin throws (nixpkgs 26.11 dropped it).
Layout: nix/common.nix (systems, pkgs, treefmt, pre-commit, dev shells default and native,
default overlay), nix/lib.nix, nix/workspace-src.nix (one source per platform from the one Cargo
workspace: the platform members, its files of the shared crates told apart by name, the data
files, and stubs for the other members, which cargo needs), nix/{windows,linux,macos}/
{build,flake-module}.nix. The dependency derivations use a manifests-only dummy source, a plain
path, so crane reads nothing built at evaluation and the Darwin outputs evaluate on Linux.
Names: unprefixed outputs are the native build (Linux: KDE; Darwin: macOS); Windows cross
outputs are windows-*; checks are windows-*, linux-*, macos-* and vm-NAME; table in docs/dev/flake.md
(next revision). One deny.toml, one format-all and one version (workspace) are used by all.
PLACEHOLDER for the agent that owns the check sets: the checks that evaluate a NixOS system
or a VM (vm-*, linux-nixos-module-eval, linux-plasma-guests-eval, linux-run-kde*) are
legacyPackages.<system>.heavyChecks.<name>, not checks, because evaluating them needs more
memory than nix flake check --all-systems can use. The Plasma guests got a stub root file system
and boot loader (mkDefault, replaced by their vmVariant) so that nix flake check can evaluate
their toplevel.
Verified: nix flake check --no-build --all-systems passes (42 s, rc 0); nix flake check
--no-build passes. Not verified: any build (next revisions record them).
The Windows fmt check ran the stable `cargo fmt` over the stubbed workspace
source: it failed on the empty stub lib.rs files of the other platforms, on
`mod linux;`/`mod macos;` of the shared entry files (the Windows source does
not have those modules), and its stable rustfmt ignores the nightly options of
rustfmt.toml. It is now a runCommand running tools/format-all --tree windows
with the nightly rustfmt over the files of the Windows source (build.real, no
stubs), file by file with skip_children.
tools/format-all runs the same check locally (--check, or --apply to format;
--tree windows|mac|kde|all; the nightly rustfmt from $RUSTFMT, PATH or the
root dev shell). mac is the explicit-file invocation of the kfm check, kde is
`cargo fmt -p ...` as the KDE check does.
Verified: in a throwaway copy of wip-cand7, --apply formats 17 Windows files
(+211 -88; crates/ komorebi-backend, bar-core, core, protocol, bar windows
modules, client windows.rs, komorebi-gui, testwin) and 12 KDE files
(+22 -29); afterwards --check passes for windows, mac and kde. The formatting
itself is not in this revision (other agents are editing those files). The nix
attribute evaluates; not built.
cargoLock, cargoToml and the vendor directory of the three flakes were taken
as "${real}/Cargo.lock" and crane.vendorCargoDeps { src = real; }. A string
that names a file inside the filtered source carries the whole source in its
context, so every edit of any file in it (a .rs file, a doc) changed the
dependency derivation (komorebi-workspace-deps, about 1000 crates) and the
dependencies rebuilt on every change: the constant COMMIT_HASH alone did not
help once the stubbed workspace source was introduced.
The lock and the root manifest are now builtins.path copies of those two
files (lockFile, tomlFile) and the vendor directory is made from the lock
(vendorCargoDeps { cargoLock = lockFile; }), so the dependencies depend on
Cargo.lock, Cargo.toml and the manifests the dummy source keeps, as before.
Verified (nix eval of drvPath in a throwaway git copy, three commits:
unchanged tree, an edit of crates/komorebi-config, a docs edit): Windows
deps and kfde deps are identical in all three (before: both changed with any
edit); Windows clippy changes with the source edit and the docs edit (docs are
in the Windows source), kfde clippy and vm stacks change with the
komorebi-config edit only; the kfm deny attribute still evaluates. The kfm
deps and clippy cannot be evaluated on this Linux host (the same change was
made there by analogy). Not built: one cold build, then a second commit must
be a cache hit.
The first darwin build of the root flake failed in komorebi-workspace-deps:
rustc 1.92.0 is not supported by sysinfo@0.39.6 (requires rustc 1.95).
rust-toolchain.toml says channel = stable, and kfm-rust-overlay was pinned
to 1d3f83ba (January 2026), whose stable is 1.92.0, while the unified lock
now has sysinfo 0.39/0.40 and parking_lot 0.13 (rust-version 1.95, the
highest in the macOS and the KDE closures by cargo metadata).
kfm-rust-overlay (flake.nix, flake.lock, and the pin in
komorebi-for-mac/flake.lock) now uses 19ecdd08, the revision the root
flake's own rust-overlay and kfde-rust-overlay lock; its stable is 1.99.1.
kfm-nixpkgs and every other input are unchanged.
Verified (nix eval of drvPath, throwaway git copy before/after): the
Windows deps, clippy and nextest, and the kfde deps, clippy, nextest and
VM suite stacks are identical; kfm deny, fmt and toml-fmt change (the
toolchain). rust-bin.stable.latest version evaluated: 1.99.1 at the new
rev, 1.92.0 at the old one. Not verified: the darwin clippy, nextest and
deps drvPaths cannot be evaluated on this Linux host (the stub source is a
derivation the host cannot build); no build run.
Candidate 4: wip-cand3c (core line with macOS on komorebi-core, HideSpot, settings S1-S3, bar e2e scenario, handover scenario fix), wip-u-core3 (shared Workspace update_shared and the Windows converge of window_manager/process_command), wip-u-stallfix (lock-holder instrumentation, sysinfo scan before the lock, bar restart and hwnd file off the lock, subscriber write timeout) and wip-u-pkg2 (one komorebi package and binary, daemons as libraries). Conflicts, if any, are resolved here.
Step 8 (Option A of docs/dev/unified-binaries.md). The main.rs of komorebi-windows, komorebi-linux and
komorebi-macos becomes daemon.rs of the library (pub fn run; komorebi:: paths are crate:: paths now, the
inner attributes and the unit tests move with it), and their [[bin]] is gone, so each is a library only.
The new package komorebi (komorebi-daemon/, version 0.1.42) is the one binary: its main calls
komorebi_windows::daemon::run, komorebi_linux::daemon::run or komorebi_macos::daemon::run by cfg_select! on
the target OS, through target-gated dependencies (one key per library, cargo allows one path per key),
and forwards the features deadlock_detection and schemars. The binary name komorebi now comes from exactly
one package. The four KDE integration tests that run the binary (no_kwin, socket, hot_reload, version)
move to komorebi-daemon/tests/linux_*.rs; the version test compares with the KDE version crate, since
the package version is now shared. Old names: komorebi-windows, komorebi-linux and komorebi-macos still
build, as libraries (no binary any more: use -p komorebi). The flakes build -p komorebi with the KDE and
macOS packages, the source filters take komorebi-daemon (manifest, main.rs, linux tests), the Windows
filter leaves its linux tests out, deny.toml clarify entries gain komorebi, the release workflow's cargo wix
and the justfile version lookup name komorebi, tools/fast-check checks -p komorebi on KDE and macOS.
Behaviour: the same code runs, the same binary name; the Windows executable is rebuilt from the library
(BEHAVIOUR for the e2e gate: the Windows e2e must run).
Gates run: Windows clippy --all-targets -D warnings PASS; KDE check; macOS fake-CC check of -p komorebi
-p komorebi-macos PASS (type check only); KDE cargo test -p komorebi -p komorebi-linux -p komorebic -p
komorebi-client -p komorebi-hotkeys -p komorebi-core: 903 passed, 0 failed (the four moved tests and the
unit test of daemon.rs included); CLI docs oracle identical x3; bar schema harness identical both bars;
kde-closure-check ok; nix evaluation of the root and both nested flakes PASS; by evaluation an edit of
komorebi/src/daemon.rs changes the Windows derivations only, of the KDE daemon.rs kfde only, of the macOS
one neither (the shared komorebi-daemon/src/main.rs changes all, as expected). Not run: nix builds, VM,
e2e, any Mac run.
New extras scenario e2e/platforms/qemu_windows/extras/bar.py, registered in
run.py as `bar` (runs after the tiling windows, like the other Windows
extras). It starts komorebi-bar in the guest with a configuration that has
storage, time, applications, komorebi workspaces and layout widgets, the
Windows-only Keyboard and Systray widgets and a `mouse` block (a message and
a command), and checks: `komorebi-bar --schema` equals the checked-in
schema.bar.json byte for byte; the process starts and its window titled
komorebi-bar appears, visible and sized; it runs 15 s (scaled); `komorebic
state` answers and komorebi does not tile the bar; commands that notify the
bar work; the bar survives `komorebic stop` and the daemon starting again as
the same process (it reconnects: it does NOT exit when the daemon stops, so
the task text "exits cleanly when komorebi stops" is checked as
`komorebic stop --bar` ending daemon and bar); screenshots are kept as
artefacts, no pixel assertions. No known failures.
Plumbing: run.py uploads komorebi-bar.exe when the binaries directory has it
(other scenarios do not need it, so older build-ref directories still work),
the nix app copies it and sets KOMOREBI_E2E_BAR_SCHEMA to the checked-in
schema (the e2e directory alone does not contain it), build-ref.sh builds it.
README and docs/dev/bar-e2e.md document it.
Verified: py_compile and ruff clean; the runner and library unit tests: 157
passed; flake.nix parses. NOT run: the scenario itself (the Windows guest is
reserved for gates), so every check is untested against a real bar and may
need adjusting (window title, timings, the Systray widget inside the VM).
Needs gate: win-e2e `bar`.
The macOS bar module moves from komorebi-for-mac/komorebi-bar/src/macos to komorebi-bar/src/macos (the
include_str! path follows), komorebi-bar/src/main.rs is a cfg_select! over target_os that runs
windows::main or macos::main, and komorebi-bar/Cargo.toml has what both share in [dependencies] and the
rest in per-target tables (Windows: windows, windows-core, windows-icons x2, systray-util, tokio, regex,
which, egui_extras, netdev 0.46, sysinfo 0.39, komorebi-themes without default features; macOS: objc2,
objc2-app-kit, icns, raw-window-handle, netdev 0.40, sysinfo 0.38, komorebi-themes with defaults), so each
platform keeps the versions it had. The old komorebi-bar-macos package stays as a shim that includes the
moved module. The macOS flake builds -p komorebi-bar and its source filter takes the unified package's
manifest, main.rs and src/macos; the Windows filter leaves src/macos out. The bar does not build for
Linux (no arm of the cfg_select), as before.
Gates run: Windows clippy --all-targets -D warnings PASS; macOS fake-CC check --locked --all-targets of
-p komorebi-bar and -p komorebi-bar-macos PASS (type check only); bar-core schema oracle (3 + 6) PASS; the
S/bar2 harness regenerates schema.bar.json for Windows (9091 lines) and macOS (3774) byte-identical to the
checked-in files; tools/kde-closure-check ok; CLI docs oracle identical x3; nix evaluation PASS and by
evaluation an edit of komorebi-bar/src/windows changes the Windows derivations only (the macOS side cannot
be evaluated on this Linux host). Not run: nix builds, any bar run (Windows screenshot gate and the Mac
hand check are owed).
The root komorebi-client package (0.1.42) is the one client: src/lib.rs is a cfg_select! over target_os
that re-exports the module of the platform. The three lib.rs files move to komorebi-client/src/{windows,
linux,macos}.rs (they were made equal in socket code by the previous revision), the KDE integration tests to
tests/linux_{daemon,subscribe}.rs (#![cfg(target_os = "linux")]). The daemon crate of each platform has a
dependency key of its own (cargo allows one path per key) and the module names it (use crate::komorebi_linux
as komorebi). The old komorebi-client-linux and komorebi-client-macos packages stay as shims that include
the moved module, so the old names build until the cutover (the macOS bar and komorebic-macos still use
them). komorebic now depends on the one komorebi-client on all three platforms. The KDE and macOS flakes
build the unified client (-p komorebi-client) and take its manifest, lib.rs and their module in the source
filter; the Windows filter leaves the other platforms' modules and tests out. Windows API for komorebi-bar,
komorebi-gui and komorebic is unchanged.
Gates run: Windows clippy --all-targets -D warnings PASS (client, bar, gui, komorebic); KDE cargo test -p
komorebi-client -p komorebi-client-linux -p komorebic -p komorebi-linux: 775 passed 0 failed (the client
tests and doctests included); cargo check of komorebic-linux and komorebi-client-linux PASS; macOS fake-CC
check --locked of komorebi-client, komorebic, komorebi-client-macos, komorebi-bar-macos, komorebic-macos
--all-targets PASS (type check only); CLI docs oracle byte-identical x3; nix evaluation PASS; by evaluation an
edit of komorebi-client/src/windows.rs changes only Windows derivations, linux.rs only kfde, macos.rs
neither. Not run: nix builds, the e2e (komorebi-client is in the closure of komorebi.exe's users: Windows e2e
OWED), any macOS link or run.
komorebi-for-kde/komorebic/src/{main.rs,hotkeys.rs,applications.json} and tests/{check,cli,hotkeys}.rs
move to komorebic/src/linux/{mod.rs,hotkeys.rs,applications.json} and komorebic/tests/linux_*.rs
(#![cfg(target_os = "linux")]). The only edits are paths: include_str! and the tests' fixture and
repository-root paths point into komorebi-for-kde/ (docs, komorebi-hotkeys, schema files),
komorebi/tests/asc.rs reads the moved applications.json. The old package komorebic-linux stays and
builds from the moved file through a shim (src/main.rs includes ../../../komorebic/src/linux/mod.rs), so
the old name works until the cutover; its tests now run in the unified package. The KDE flake builds and
tests komorebic (unified) instead of komorebic-linux, its source filter takes the unified package's
manifest, build.rs, main.rs, src/linux and tests/linux_*; the Windows source filter leaves the Linux
and macOS files out. Comments and docs that name komorebic/src/main.rs or komorebic/tests/*.rs
(check.rs, ARCHITECTURE.md, scripts/compare-gen.py, the VM check suite) were not touched: they would
change the KDE derivations for text only.
Gates run: KDE cargo test -p komorebi-linux -p komorebic -p komorebic-linux -p komorebi-client-linux
-p komorebi-hotkeys --no-fail-fast: 888 passed, 0 failed (the moved komorebic tests included); Windows
clippy -D warnings PASS; macOS fake-CC check PASS; fast-check nix evaluation PASS; CLI docs oracle for
kde now generated by the unified komorebic: 166 pages, 0 diff, and its --help first line and --version
equal the old package's. Not run: nix builds (the KDE derivations changed), VM suites. Note: cargo
build/test of both komorebic and komorebic-linux in one command writes the same binary name twice
(use one of them).
The three flakes now build from the one root Cargo workspace (previous revision, which must land with
this one). nix/workspace-src.nix assembles each platform's source: the files it needs (its crates, the
root crates they depend on, the root Cargo.toml and Cargo.lock) plus a stub (the member's own
manifest, an empty lib.rs, a main that does nothing) for every other member, because cargo has to load
the whole workspace but must not depend on the other platforms' code. The KDE and macOS flakes pass
-p <their packages> (cargoExtraArgs), no longer cd into a subdirectory workspace, use the root
Cargo.lock/Cargo.toml (vendored from the filtered source, so crane does not read the stubbed one),
and run cargo deny with --workspace --exclude <the other platforms' packages> and their own
deny.toml; the root flake excludes the KDE and macOS packages from deny and builds default-members.
komorebic/applications.json is added to the macOS source filter (it is embedded by include_str!).
The KDE/macOS deny.toml clarify entries and root deny.toml follow the package renames (squashed into
the rename revisions).
Evaluation (nix eval drvPath, no build): Windows clippy, deny, fmt, nextest, toml-fmt; kfde clippy,
doc, deny, fmt, toml-fmt, nextest, schema-fresh; kfde-komorebi, kfde-komorebic, komorebic. Cache
isolation measured by evaluation: an edit of crates/komorebi-bar-core or komorebi/src changes the
Windows drvs and leaves the kfde clippy and nextest drvs unchanged; an edit of komorebi-for-kde changes
kfde and leaves Windows unchanged; an edit of komorebi-for-mac changes neither. tools/kde-closure-check
ok (rewritten for the merged workspace), root-crates.json unchanged.
KNOWN LIMITS: (1) the stubbed source is a derivation that crane reads at evaluation (readDir in
mkDummySrc), so evaluating or building another system's attributes needs a builder for that system:
`nix flake show --all-systems` and drvPath of aarch64-darwin attributes now fail on a Linux host (the
fast-check nix step evaluates the current system only). (2) cargo deny, fmt and taplo behaviour in the
merged workspace is unverified: not built. (3) the version placeholder warning of crane for the
virtual root manifest (cosmetic).
Needs from the coordinator (idle host, heavy gates): nix build -L .#checks.x86_64-linux.komorebi-workspace-clippy
(the root deps derivation is a new one because of the lock), .#checks.x86_64-linux.komorebi-workspace-deny,
-fmt, -nextest, -toml-fmt; the same for kfde-komorebi-workspace-{clippy,deny,fmt,nextest,toml-fmt,doc},
kfde-schema-fresh, .#packages.x86_64-linux.kfde-komorebic and kfde-komorebi; then one KDE VM fast run
(the KDE package derivation changed); on a Mac or a darwin builder: .#packages.aarch64-darwin.kfm-komorebic,
kfm-komorebi, kfm-komorebi-bar and the kfm checks. Not run by me: any of these.
COMMIT_HASH was in commonArgs, so buildDepsOnly (about 1000 dependencies)
and every check (clippy, nextest, fmt, deny) got a new derivation for every
commit, even a docs-only one, and rebuilt in full.
commonArgs now carries the constant "nix-check" (as the KDE flake already
does) and only fullBuild, and so packages.default and the extracted
binaries, gets the real commit. The e2e build keeps its own constant through
the existing `commit` argument. Nothing the checks compile or test changes;
only the string shadow_rs stamps into the check binaries.
Verified (nix eval of drvPath in a throwaway git copy, 7 commits): the deps
derivation is identical for a docs edit, a Windows source edit, another docs
edit, a bar-core edit and a KDE-crate edit; clippy, nextest and fmt are
unchanged by the docs edit and change only for source edits;
packages.default changes with every commit (real commit embedded). Not
verified by a build: needs one idle-host nix build (commands in
tools/README.md).
The root flake got the code of komorebi-for-kde and komorebi-for-mac through two locked path inputs (kfde, kfm), so the root flake.lock pinned the content of those directories and needed 'nix flake update kfde kfm' after any edit under them; a stale pin gave 'attribute lib missing'.
Now the root imports komorebi-for-kde/flake.nix and komorebi-for-mac/flake.nix as plain files and calls their outputs/lib.mkOutputs with inputs declared in the root under the names kfde-* and kfm-* (nixpkgs, nixpkgs-lib, flake-compat, flake-parts, crane, rust-overlay, treefmt-nix, git-hooks-nix, and gitignore for kfm), pinned by revision in the URL to exactly the revisions of each nested flake.lock, with the same follows structure. The nested flakes are unchanged and still have their own locks. The kfde and kfm nodes are gone from flake.lock. When a nested flake.lock is bumped, update the revisions of the matching kfde-*/kfm-* inputs by hand.
Verified (tier 2): derivation paths unchanged before and after for kfde fmt, deny, nextest, schema-fresh, the Windows workspace clippy check, kfde-komorebic and kfm-komorebic (aarch64-darwin, eval only); every narHash of the nested locks is present in the root lock; nix flake check --no-build passes on x86_64-linux; nixosModules, overlays, darwinModules evaluate; kfde-vm has 34 suites.
The root flake no longer re-exports the nested flakes' own outputs. It keeps them as inputs for their pinned nixpkgs, crane and rust-overlay (inputs.<name>.inputs), but calls their lib.mkOutputs with the whole repository (self) as the source, a nested self carrying the root rev, dirtyRev and inputs, and the tree's directory, then re-exports packages, checks (without vm-*), legacyPackages.kfde-vm, nixosModules, overlays and darwinModules from those. flake.lock is updated for the changed nested flakes: the lock pins their content, so it needs 'nix flake update kfde kfm' whenever a file under komorebi-for-kde or komorebi-for-mac changes.
Verified (Linux, x86_64): nix build -L of packages.kfde-komorebic and kfde-komorebi succeed and both binaries run with --help (exit 0); checks kfde-schema-fresh, nix-options-validation, keybindings-fixtures, komorebi-bridge-js, nixos-module-eval, plasma-guests-eval, run-kde-dry-run, run-kde-doctor, komorebi-workspace-fmt, -deny and -nextest build; kfde-komorebi-workspace-toml-fmt FAILS because komorebi-for-kde/Cargo.toml itself is not taplo-formatted (same result running taplo on the file directly; not caused by this change). nix eval of aarch64-darwin kfm-komorebic and kfm-komorebi drvPath print .drv paths (evaluated, not built). Windows clippy and default drvPaths are identical to those before this revision. nix flake check --no-build passes for x86_64-linux. Not verified: any darwin build, kfde clippy/doc, the VM suites.
A path flake (a jj workspace without .git) has neither rev nor dirtyRev, so the commit stamp default in mkKomorebiPackages failed to evaluate. It now falls back to "unknown", as the nested flakes do.
Verified: nix eval --raw .#checks.x86_64-linux.komorebi-workspace-clippy.drvPath now prints z9nb5j12qlfp1j8d71ykp9qnafk553ra-komorebi-workspace-clippy-0.1.0.drv (it failed before); .#packages.x86_64-linux.default.drvPath is cq0i40300hgsm0ih2llcdjpkcg9sfqaf-komorebi-workspace-0.1.0.drv. Neither was built.
Phase 1 of A3b. The root flake imports the nested flakes' lib.mkOutputs with the whole repository as source and re-exports packages, checks (without vm-*), nixosModules, overlays and darwinModules with kfde-/kfm- prefixes. Windows outputs are untouched. Verified: the KDE package builds; the macOS package evaluates (not built).
Excludes /komorebi-for-kde and /komorebi-for-mac from the Windows crane source filter so their edits do not invalidate Windows builds and their Cargo.lock files are not swept in. Verified: the Windows clippy check still passes.
komorebi/src/pan.rs and komorebic/src/pan.rs include_str! the .txt files in komorebic/fixtures/, which the crane source filter dropped, so the nix build failed. Adds the fixtures to the filter. Verified: nix komorebi-workspace-clippy passes.
komorebic's build script (reqwest) runs on the build host and needs
pkg-config and OpenSSL, as in the nix build, so cargo test --workspace works
from nix develop.
komorebi-testwin-e2e is the e2e build's test window, so a change to it
rebuilds the crate and not its dependencies (86 s instead of minutes);
build-ref.sh uses it.
COMMIT_HASH is in the derivation of the dependencies too, so every commit
rebuilt everything for nix run .#e2e-windows. The e2e build stamps e2e;
the commit under test is KOMOREBI_E2E_COMMIT.
build-base.sh does the unattended install (about 18 minutes) and
build-golden.sh puts policies, Defender and the display driver on top of
it in about 2.5 minutes through the guest agent (provision.ps1). A qcow2
chain with a relative backing path keeps the two together.
build-ref.sh builds komorebi and komorebic of any commit, and
KOMOREBI_E2E_BINS makes nix run .#e2e-windows test those binaries.
E2E_GOLDEN names the golden image built by build-golden.sh; the komorebi,
komorebic and test window binaries, QEMU, swtpm and an OVMF with TPM support
come from the flake. Also exposes the guest agent and the test window as
packages.
xwin makes case-alias symlinks on a case-sensitive filesystem and none on a
case-insensitive one, so the SDK hash depended on the host. Build with
--disable-symlinks, pin that tree's hash, add the CA bundle xwin needs, and
add the lowercase aliases the linker asks for in a separate derivation.
I was getting really tired of having to switch between display inputs to
different platform-specific machines to be able to make and test changes
on komorebi for Windows and komorebi for Mac.
With this commit, the `flake.nix` provides a Nix devShell and crane
build for users to make and validate changes with `cargo check`, `cargo
clippy` and `cargo build` with the Windows MSVC toolchain on Linux and
macOS.
LGUG2Z