EEZ Studio Build Output Manifests: Avoid Sharing One Generated Directory Between Projects

Two EEZ projects should not casually share one generated-output directory. In the inspected build implementation, that directory also contains a manifest of the previous generated files. A later build uses the previous list to identify files that should be removed.

The Settings guide describes the build destination. The cleanup mechanism is visible in build.ts at editor commit 3000161d09d40a5c1dc2477ddc30b38037b3a612, corresponding to the inspected EEZ Studio v0.29.0 source.

The scope is the non-Dashboard build-files path. This is not a claim that every build command recursively removes arbitrary files, or that a particular user's project has lost data.

The directory carries a previous-file list

The build code attempts to read .eez-project-build from the destination directory and parse it as a manifest. The saved manifest contains a files list. Generated writes are tracked so the current operation can construct its own list.

Near the end of the build-files path, the implementation compares those lists. Entries present in the previous manifest but absent from the current set become orphan candidates. The cleanup function joins each relative entry to the destination path and attempts to unlink that file.

This is a set difference, not a judgment about whether the file still matters to a human or another project. If project A's generated file is listed in the shared directory's previous manifest and project B does not generate it, that file can enter the cleanup set during B's build.

A simple example exposes the collision

Imagine that A's previous list contains screen_a.c and common.h. B's current list contains screen_b.c and common.h. The previous-minus-current set contains screen_a.c. The same-name common.h entry is not an orphan by this comparison, although its content may now belong to B's generated output.

These are two different collision modes: an A-only artifact can be removed, while a shared filename can be replaced by the current generator. Checking only whether common.h still exists misses the ownership change.

The example is illustrative. Actual generated names and file tracking depend on the project and build configuration. Inspect the manifest the selected version actually writes rather than assuming the example names are EEZ defaults.

Give each project its own destination

Separate output directories give each project a separate manifest and cleanup namespace. An integration build can then consume the intended generated directory explicitly, instead of relying on whichever project most recently wrote into a common folder.

Keep handwritten integration code outside a directory whose generated-file ownership is ambiguous. The cleanup function described here acts on previous manifest entries, not every unlisted file. Nevertheless, relying on a file's accidental absence from the manifest is weaker than assigning the directory a clear owner.

Do not treat hand-editing the manifest as the normal integration strategy. The next successful build saves a new generated-file list. A manual exception can disappear, and a manifest copied from another tree may describe the wrong files.

Verify cleanup only in a disposable tree

Create two minimal non-Dashboard project copies and one empty scratch destination. Build A, then preserve its manifest and a file listing. Build B into that same scratch destination and compare the resulting files with the two manifests.

Observe the cleanup messages as supporting evidence, but inspect the files too. The unlink loop catches errors, so an attempted cleanup and an actually removed file are not interchangeable observations. A missing or unreadable previous manifest also changes the available cleanup information.

Repeat with separate destinations to establish the intended ownership arrangement. Then review the native build's source paths so it does not accidentally keep compiling an older shared directory after the generator destination changes.

No EEZ build or deletion experiment was executed here. The source establishes a concrete output-directory contract: a previous generated-file list can authorize cleanup relative to the next generated set. Keeping that list owned by one project prevents a directory-sharing convenience from becoming an unintended cross-project cleanup operation.