makeover-build

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

Every consumer materialises the same generated files from a build.rs. This is that code, once, so no consumer keeps its own copy.

// build.rs
fn main() {
    makeover_build::tauri_frontend(env!("CARGO_MANIFEST_DIR"), &makeover_build::Emit::default());
    tauri_build::build();
}

That writes themes/ beside the manifest and frontend/css/layout.css under it, which is where both Tauri apps already look. Consumers wanting different paths call themes and layout_css directly.

What is deliberately not here

The geometry emitter. GoingsOn scopes the touch preset to a ui-mode-mobile class set by a bootstrap script, Balanced Breakfast 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 point. A helper crate should record agreement, not manufacture it.

Why these files are generated

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.

themes clears stale .toml files before writing, so a theme removed or renamed upstream does not linger in the bundle from a previous build. Omitting that step shows up as a theme that will not go away.

Status

Unpublished, path deps on makeover and makeover-webview. Consumers are GoingsOn and Balanced Breakfast.

Licence

MIT.