A teammate can't open my project / paths broke¶
A .und project records where each source file lives. When you share the project — or move it to
another machine, or a CI agent checks the source out to a different location — those recorded paths may
no longer point at the files. The result: files show as missing, or analysis can't resolve them, even
though the source is right there.
The cause is almost always absolute paths recorded on the machine that created the project. The fix is to make the project portable.
Two ways to make it portable¶
- Relative paths — record file paths relative to the project, for source that always sits in a fixed layout beneath it.
- Named Roots — map a symbolic name (e.g.
SRC) to a directory. Each machine points the same root name at its own checkout location, so files beneath it stay resolvable everywhere.
For the full command reference and CI workflow, see Portable projects & Named Roots. The short version:
Find what's broken¶
From the command line, list files that aren't resolvable or portable:
und list -unmapped roots MyProject.und # Named Roots undefined on this machine
und list -unportable roots MyProject.und # files neither mapped to a root nor relative
Fix it¶
Point each Named Root at the local checkout path:
und add -root SRC=/path/to/checkout/src MyProject.und
Record new files as relative and/or define Named Roots, then enforce portability so non-portable paths can't creep back in:
und settings -enforceportability on MyProject.und
Send a recipe, not just the .und
For a team, commit the .und (or a script that rebuilds it) to version control, and document the
Named Root each person sets on their machine. That's more robust than emailing a project full of
one person's absolute paths.
Sharing analysis data is a different trade-off
und create -local shares the parsed data but requires identical file paths on every machine —
the opposite of Named Roots. For a team with differing checkout paths, use Named Roots and
re-analyze on each machine. See Portable projects & Named Roots.