Skip to main content
This feature is only available in Incredibuild’s Enterprise and Business Plans.
Auto-generated code is fully supported, but it may affect Build Cache performance. In many projects (e.g. Unreal Engine) code is generated automatically from other code or resources. There is nothing inherently bad with auto-generated code, and it’s possible that Build Cache will treat it efficiently. For example, consider the following header file which is automatically generated (from some input file that has the value of 17):
If the input file that contains the constant 17 is unchanged, then the header file won’t change, and Build Cache will efficiently cache any C or C++ files that include this header. However, if the auto-generated code contains some text that changes in every build (such as timestamps, build versions, etc.), then any file that includes this header will re-compile at every build. This is true even if these changing texts are placed in comments.

​
Comments in Auto-Generated Code

Typically, auto-generated code may contain a comment that indicates it is auto-generated, for example:
The comment may contain the name of the script or tool that generates the code (foo-generator.exe in the above example). Developers typically do this to make sure no one changes the generated code manually, since such changes get overwritten on the next build.

​
Comments with Timestamps

Consider the following header file which is automatically generated during the build:
The auto-generated header is now different in every build (because of the file creation timestamp). Even though the change is in a comment and does not affect the code execution, Build Cache considers these as differences and will recompile any C or C++ file that includes it. In such situation, we recommend that you change the way this code is generated (change foo-generator.exe) and remove the changing text.

​
Comments with Changing File Names

Consider the following header file which is automatically generated during the build:
The header comment contains the name of the “source” file for the generated code (Version.xml in the above example). However, in this example the file name contains the full path to the source file. Sometimes that’s fine, but in the above example it is apparent that the path contains a random folder. This might be a CI job that generates a new folder for every build. This means that the file above changes at every CI job, and Build Cache considers that as changed code which requires re-execution. In such situation, we recommend that you change the way this code is generated (change foo-generator.exe) and switch from using a full path to relative path.

​
Other Examples

A more complex situation can arise when the auto-generated code actually affects the program execution. For example, consider a header file that contains a function that returns the build ID (e.g. 37198):
Again, since the auto-generated header is now different in every build, Build Cache considers these as different code and will recompile any C or C++ file that includes it. In such situation, we recommend making sure that this header is only included when needed. The fewer files include it, the more efficient Build Cache will be.