RAD Studio .dproj absolute paths break cross-machine builds

Direct resolution

Use $(PROJECTDIR)-relative macros inside each .dproj for project-local search paths, and coordinate shared dependencies through environment variables in the global IDE Library Path. Project Groups (.groupproj) do not convert absolute paths automatically; every member project must be normalized individually.

Likely explanation vs. confirmed behavior

The most likely explanation for broken cross-machine builds is that search paths were added through the IDE's browse dialog, which writes absolute filesystem strings into the .dproj XML. This is default IDE behavior, not a defect.

Confirmed, well-established behavior:

• .dproj search-path elements such as <LibPath> accept $(PROJECTDIR) macros that resolve from the project file's location.
• Global Library Path entries in Tools > Options can reference environment variables using %VAR% syntax.
• A .groupproj references member projects but does not rewrite or normalize their path entries.

Steps for this case

1. Open the .dproj in a text editor. Replace absolute roots in <LibPath> (and related unit-search-path elements) with $(PROJECTDIR)-relative values that match your repository layout, for example $(PROJECTDIR)\..\..\libs.
2. For dependencies outside the project tree, define an environment variable on each workstation (for example, MYLIB) and enter %MYLIB% in the global Library Path. Avoid duplicating that absolute path inside the .dproj.
3. If you use a Project Group, repeat the normalization for every .dproj in the group; the group file itself does not enforce a path strategy.

Verification

• Search the .dproj for <LibPath> entries that contain neither $(PROJECTDIR) nor a % variable.
• Clone the repository to a different root on a second machine and build. Confirm that all units resolve without missing-unit or missing-library errors.
• Check that global Library Path entries use %VAR% syntax rather than absolute C:\ paths.

One diagnostic that changes the recommendation

Do your shared dependencies live in a fixed relative position to the .dproj (for example, a sibling libs folder inside the repository), or are they installed in machine-specific absolute locations? If they are outside the repository and not in a consistent relative location, $(PROJECTDIR) alone is insufficient and the environment-variable strategy is mandatory rather than optional.