oxidecomputer / oxidecomputer/hubris

Cleaning everything on app.toml changes shouldn't really be necessary

Open
#240 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

build developer-experience Triaged H2'26
Dominant language
Rust
Stars
3.6k
Forks
239
Avg merge
1d 12h
Merged PRs (30d)
23

Description

Currently, xtask dist runs around cleaning things whenever app.toml changes. This was originally done so that switching between apps didn't accidentally link in each others' objects. It's kind of annoying, however, and shouldn't be strictly necessary ... if we've got all the various build dependencies right. It may be masking cases where we forgot to (say) emit a cargo:rebuild-if-whatever line from the build script.

It would be great for one of us to investigate and make this more precise, as it should dramatically reduce build times for people working on more than one app.

It's also going to become increasingly important as we move more config information into the toml, since right now, changing (say) the proposed i2c config tree will force a rebuild of all tasks, which is overkill.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how xtask dist reacts to changes in app.toml, then inspect the build scripts and their cargo:rebuild-if-whatever dependencies. Identify which configuration changes actually require rebuilding or cleaning instead of triggering a full cleanup. Done means switching apps and changing targeted TOML configuration no longer causes unnecessary rebuilds while avoiding stale objects.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
build-system, embedded-iot
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.