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.
// build.rs
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 an earlier build. That is
the detail that makes this worth sharing rather than retyping: it is easy to
omit, and its absence 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.