Which project folders are important?

I would assume that the folders named “Build” and “Intermediate” are not important, and that I can wipe the content from both of them and regenerate them through automated re-build steps.

However, when trying this, the following happened:

  • my Android SDK configuration was detected as “not configured”
  • my Google Play services were detected as “not configured”
  • all the Android icons were reset to the default Unreal icon
  • the Windows project icon was reset to the default Unreal icon
  • the C++ code solution for Visual Studio failed to build, because the Application.ico file is referenced from there but missing

Re-configuring these things made it work again, and re-setting the icon to my intended icon made the C++ project build again.

So, this experience makes me wonder: What are the rules for where “source data” lives, versus where “generated data” lives?
It seem an awful much like there is some source-like data that lives in Intermediate, although most of the data in there is generated data.
However, that would mean that generated/built data, and actual source data, are mixed in the same directory, which is generally a pretty bad idea – so, am I missing something here?

Also, where can I read about subjects like these? I’ve looked at the Unreal build documentation, and I can’t find a section that’s deep enough to consider things like this.

So, some more learnings:

The keystore file for signing android goes into Build. This is not documented in the Android documentation, but in the tooltip help for the android project settings panel (!) Thus, after nuking the Build directory, I have to re-copy the keystore into its safe home. Additionally, this keystore is copied into the Intermediate directory during the build process, and if it’s not in the Build directory, there’s no error referring to that location; only a very late error in the Android packaging process where it fails to find the Intermediate key store.

The visual studio projects need to be re-generated. There’s no good way to do this from the command line for a project; I have to dig up the project file in Explorer and right-click and select a context menu option to do this.
These project files are generated into the Intermediate directory.

Various generated files also go into the Build directory. For example, FileOpenOrder\EditorOpenOrder.log, Android\proguard-project.txt, Android\res, etc.
Thus, while it may be that the idea is “Build contains user-defined build information, and Intermediate contains generated information that can be nuked for a clean build,” that rule is not actually followed correctly, and generated versus source data intermingle.

For those who don’t understand why this matters, consider that, if I want to “git add .” my project (managing it from outside the Unreal editor,) I need a .gitignore that excludes any generated files. Unfortunately, this rule is not simply “exclude the Intermediate directory.”

3 Likes

Some more refinement on what I’ve found. I’d really appreciate it if someone could give a yea/nay on this:

Saved/ – cached/built stuff that can safely be deleted
Binaries/ – built output binaries that can safely be deleted, although you’ll need to re-build some DLLs when re-opening a project
Intermediate/ – theoretically safe to delete the contents of, although some bits and pieces may require re-configuration (and you’ll need to re-generate your visual studio projects at a minimum)
Build/**/FileOpenOrder/ – generated file presumably used to optimize the pak files generated. Safe to delete; gets re-generated (and must be git ignored explicitly)

You’ll want to include these in your backups/source control/whatevers:
Build/
Config/
Content/
Plugins/
Source/
*.sln
*.uproject
*.png (not strictly necessary – used as preview in the launcher)

3 Likes

The plugins inside of Plugins are something of a microcosm unto themselves: inside of each plugin folder there is a Binaries, Content, Intermediates, Resources (kind of like Build, typically contains the icon for the plugin), Source, etc… Same rules apply, if you have source code you can delete Binaries and Intermediates, but if it’s a plugin from a 3rd party that you don’t have source code for then you should leave Binaries alone.

Cheers,
Michael Noland

Thanks; that’s great to know! Very helpful.

I’m assuming the rest of my investigation was correct, then? I also think that Saved/ is safe to delete?
And what about those auto-generated files going into Build/ – is that supposed to happen, or an accident of development?

Yeah, you can delete Saved whenever. It’s where logs, performance captures, etc… are saved, but also where save games are saved by default for unpackaged games IIRC (packaged ones save them to the user documents dir or something like that, so they’ll work on UAC machines).

I’m not 100% sure about those order files in Build. I think they’re put there so you can force a specific packaging order if you’re optimizing for slow media like an optical disk, but I’m not 100% sure. In any event you can certainly delete them.

Cheers,
Michael Noland

Interesting topic, I was just trying to figure out the same.

There should be a “clean project” button or menu in the unreal engine GUI imho or some intergation with git/svn/others prepared to ignore non relevant files. I hope they will develop that feature.

1 Like

Hey,
very interesting topic. I´m running into these questions too and wanted to know what i MUST check into my repository of our perforce server.
Could you figure out whats about this folder Build?
I thought it must be ok when only checking in the DLL´s in Binaries, Config, Content, Source and the Project.uproject file.
But this seemed not to be all the project needs to start. Now im struggling to find out what is really needed to not providing trash into the repository.

Best regards,
Darkentik

Very interesting topic, thanks for your investigation!!

As projects get bigger and bigger, back-ups start becoming very heavy and the project becomes really slow to transfer between team members, so all these tips on what folders are safe to be deleted are indeed very useful!!