Crate makeover_build 

Build-script support for the make-family design system.

Every consumer materialises the same generated files from a build.rs, and until now every consumer wrote that code itself. GoingsOn and Balanced Breakfast grew byte-identical copies of the theme materialiser during the makeover-geometry adoption, and the layout stylesheet would have been the third and fourth copies. This is that code, once.

What is deliberately not here

The geometry emitter. GoingsOn and Balanced Breakfast do not agree on it: GO scopes the touch preset to a ui-mode-mobile class set by a bootstrap script, BB hangs it off @media (hover: none), and audiofiles has no switch at all. Extracting it would mean picking one of those policies by accident, inside a shared crate, without anyone deciding. Density selection is unowned and has its own task; the geometry half lands after it.

Taking the identical half now and leaving the contested half alone is the whole point: a helper crate should record agreement, not manufacture it.

Why these files are generated rather than checked in

Tauri’s resource globs are read by its CLI against the crate directory, so they cannot point into a registry checkout or OUT_DIR. Materialising into the crate keeps the source crate authoritative without vendoring a second copy that drifts. Every path written here is expected to be gitignored.

Structs

Emit

Re-exported so a consumer’s build.rs needs one dependency rather than three. Nothing here wraps it; the emitter’s options are the emitter’s. How the emitted CSS is shaped.

Functions

geometry_css

Write makeover-geometry’s spacing layer, with its canonical density selection, to path.

layout_css

Write makeover-webview’s component stylesheet to path.

tauri_frontend

All three generated files at the layout every Tauri consumer already uses: themes/ beside the manifest, and frontend/css/{geometry,layout}.css under it.

themes

Write the themes makeover ships into dir, as <id>.toml.