What
When no --derived-data-path is passed, tuist inspect build and tuist inspect tests now infer the DerivedData location the same way Xcode does, instead of always appending <name>-<hash> to the default directory.
Why
The inference only handled Xcode’s default DerivedData location. A custom IDECustomDerivedDataLocation (Xcode > Settings > Locations > Derived Data) was not supported:
- A relative location (e.g.
.derived-data) couldn’t be validated as an absolute path, so it fell back to ~/Library/Developer/Xcode/DerivedData and the Logs directory was never found.
- A relative location uses a different per-project folder than the default: just
<workspaceName> with no hash (the folder sits next to the workspace).
Xcode infers the mode from the shape of the string, with no companion key. The supported rule is now:
IDECustomDerivedDataLocation |
Root |
Per-project folder |
| missing (Default) |
~/Library/Developer/Xcode/DerivedData |
<name>-<hash> |
| absolute (Custom) |
the value |
<name>-<hash> |
| relative (Relative) |
<workspace dir>/<value> |
<workspaceName> (no hash) |
How
- New
DerivedDataLocation enum in TuistEnvironment with a pure classify(rawLocation:).
- New
Environment.derivedDataLocation() seam (reads IDEDerivedDataPathOverride / IDECustomDerivedDataLocation); derivedDataDirectory() now returns only the global default.
DerivedDataLocator.locate resolves root + whether to hash from the mode, keeping DERIVED_DATA_DIR / BUILD_DIR precedence (set by Xcode during post-actions).
Both inspect build and inspect tests benefit, since both go through DerivedDataLocator.locate.
Validation
xcodebuild test ... -only-testing TuistXcodeBuildProductsTests passes, including new tests for the pure classifier and for the relative/custom/precedence cases. (The one unrelated failure in that target is a pre-existing locale-dependent AppBundleLoaderTests assertion comparing a Foundation error string in English.)
T
