Best practices for Perforce ignore rules with Engine Source and mixed binary folders

Development Platform & Builds
, , , ,
1

We are currently using a local copy of the UE5 source code alongside our project and would like to clarify the best practices for managing Perforce ignore rules for engine binaries.

The main challenge is that several engine directories contain a mix of shippable binaries (required for the engine to run) and generated artifacts (derived during the build process). Manually adding every generated file to the ignore list is not ideal, as it is error-prone and could negatively impact p4 reconcile performance as the file list grows. Furthermore, this approach makes it difficult to track when new shippable binaries are added or existing ones are removed during engine updates.

How does Epic Games recommend structuring .p4ignore.txt or workspace mappings to cleanly separate these files without manual maintenance?

This is how it works now.
```
Binaries/Win64
!Binaries/Win64/LivePlusPlus/
!Binaries/Win64/RedDebugger/
!Binaries/Win64/UnrealBuildAccelerator/
!Binaries/Win64/UnrealInstrumentation/
!Binaries/Win64/AnalysisTabUtils.exe
!Binaries/Win64/AnalysisTabUtils.pdb
!Binaries/Win64/CmdLink-BuildSettings.dll
!Binaries/Win64/CmdLink-Core.dll
!Binaries/Win64/CmdLink-TraceLog.dll
!Binaries/Win64/CmdLink.exe
!Binaries/Win64/EpicWebHelper.exe
!Binaries/Win64/EpicWebHelper.pdb
!Binaries/Win64/EpicWebHelperarm64.exe
!Binaries/Win64/EpicWebHelperarm64.pdb
!Binaries/Win64/LiveCodingConsole.exe
!Binaries/Win64/MinidumpDiagnostics.exe
!Binaries/Win64/MinidumpDiagnostics.pdb
!Binaries/Win64/PatchTabView.exe
!Binaries/Win64/PatchTabView.pdb
!Binaries/Win64/ProcessSymbols.bat
!Binaries/Win64/UnrealTraceServer.exe
!Binaries/Win64/UnrealTraceServer.pdb
!Binaries/Win64/UnrealVersionSelector-Win64-Shipping.exe
!Binaries/Win64/UnrealVersionSelector-Win64-Shipping.pdb
!Binaries/Win64/crashpad_handler.exe
!Binaries/Win64/iostore_analysis.exe
!Binaries/Win64/iostore_analysis.pdb
!Binaries/Win64/msdia140.dll
!Binaries/Win64/radpatcher.exe
!Binaries/Win64/radpatcher.pdb
!Binaries/Win64/zen.exe
!Binaries/Win64/zen.pdb
!Binaries/Win64/zenserver.exe
!Binaries/Win64/zenserver.pdb
```

2

I too would like to know this. To be honest it’s shocking that this isn’t documented somewhere by Epic themselves. Seems absolutely fundamental to using a Source build.

3

As far as I know Epic doesn’t document this anywhere, probably because every studio ends up with its own rules. So this is just how we do it.

P4IGNORE only applies to files that aren’t in the depot yet. Anything already submitted stays tracked, whatever the ignore file says. So you don’t need the ignore file to work as a whitelist, the depot already does that. Start from a clean engine tree (source plus Setup.bat, nothing built), submit it as is, and only then add broad rules:

Intermediate/
DerivedDataCache/
Saved/
Binaries/

The binaries from the clean tree stay versioned, whatever the build generates afterwards is ignored, and you can drop the whole list of ! exceptions. If a build later modifies one of those tracked binaries, reconcile will show it, and that usually means the file is a build output and shouldn’t be in the depot.

On the project side, before the first submit we run a small .bat from the project root so nothing generated goes in. It only wipes the three cache folders and leaves Binaries alone:

@echo off
REM Run from the project root, next to the .uproject
for %%d in (DerivedDataCache Intermediate Saved) do (
    if exist "%%d" (
        echo Deleting %%d...
        rmdir /s /q "%%d"
    )
)
echo Done.
pause

For engine upgrades, keep a separate stream that only receives clean Epic drops, e.g. //UE5/Epic-5.7. Replace the tree there with the new version and run p4 reconcile -I, which skips the ignore rules. Nothing is ever built in that stream, so the reconcile shows exactly which shippable binaries were added, removed or changed. Then integrate into your dev stream. No manual list to maintain.

Two more things. The ignore file does nothing on a machine where P4IGNORE isn’t set (p4 set P4IGNORE=.p4ignore.txt), and one machine without it is enough to get generated files submitted again. And the rules don’t untrack files that were already submitted by mistake. For those, p4 delete -k removes them from the depot and keeps the local copies.

Disclosure: I’m building Gameheim, a hub for Unreal teams on top of Perforce. Because of that first problem, in Gameheim the ignore file is a project setting: a Lead edits it, it gets submitted to the depot and written into every teammate’s workspace (offline machines get it when they reconnect), and our agent applies it even where P4IGNORE isn’t set. P4V and the editor still need the variable, though.