# FASTBuild generator Unity build issues
**URL:** https://discourse.cmake.org/t/fastbuild-generator-unity-build-issues/15634
**Category:** Development
**Created:** [April 27, 2026, 7:49pm UTC](https://discourse.cmake.org/t/fastbuild-generator-unity-build-issues/15634 "2026-04-27T19:49:00Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@kamchatka-volcano](https://discourse.cmake.org/u/kamchatka-volcano)
#### Post date: [April 27, 2026, 7:49pm UTC](https://discourse.cmake.org/t/fastbuild-generator-unity-build-issues/15634/1 "2026-04-27T19:49:00Z")
Hi, thanks a lot for adding support for FASTBuild!
I’m experimenting with enabling it in a large CMake-based project, and I noticed several quirks:
1. Is there any technical reason to use `UnityInputIsolatedFiles` instead of `UnityInputExcludedFiles` for source files with enabled `SKIP_UNITY_BUILD_INCLUSION`?
Isolated files prevent caching, which is undesirable when a fairly large number of files are skipped from Unity. Can `UnityInputExcludedFiles` be used instead?
[https://github.com/fastbuild/fastbuild/issues/1184](https://github.com/fastbuild/fastbuild/issues/1184)
2. It seems that the FASTBuild generator doesn’t respect this rule: “Any source file that has a non-empty `COMPILE_OPTIONS`, `COMPILE_DEFINITIONS`, `COMPILE_FLAGS`, or `INCLUDE_DIRECTORIES` source property will not be combined into a unity source.”
We disable warnings in some of our code-generated files (QML) by using `COMPILE_OPTIONS` and do not add them to `SKIP_UNITY_BUILD_INCLUSION` explicitly. These source files compile individually with the Ninja generator, but with FASTBuild they are placed into Unity batches.
3. It seems that the batching algorithm was changed between versions 4.2 (splitting source files by batch size and folder boundaries) and 4.3 (splitting source files only by batch size). This change is probably deliberate because version 4.3 follows `UNITY_BUILD_BATCH_SIZE` more closely and matches the batching behavior of other generators. However, in our project, version 4.2 is surprisingly much more performant (20–30% faster).
Can you consider making it configurable and allowing users to select the 4.2 batching behavior in future versions?
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [April 27, 2026, 9:06pm UTC](https://discourse.cmake.org/t/fastbuild-generator-unity-build-issues/15634/2 "2026-04-27T21:06:09Z")
Cc: @Eduard_Voronkin
---
### Author:  [@Eduard\_Voronkin](https://discourse.cmake.org/u/Eduard_Voronkin)
#### Post date: [May 10, 2026, 6:54pm UTC](https://discourse.cmake.org/t/fastbuild-generator-unity-build-issues/15634/3 "2026-05-10T18:54:09Z")
The first issue is tracked here: [https://gitlab.kitware.com/cmake/cmake/-/work\_items/27784](https://gitlab.kitware.com/cmake/cmake/-/work_items/27784)
The second issue is tracked here: [https://gitlab.kitware.com/cmake/cmake/-/work\_items/27805](https://gitlab.kitware.com/cmake/cmake/-/work_items/27805)
I’ll think a bit more about the third one, perhaps we can make it configurable
---
### Author:  [@kamchatka-volcano](https://discourse.cmake.org/u/kamchatka-volcano)
#### Post date: [May 10, 2026, 8:54pm UTC](https://discourse.cmake.org/t/fastbuild-generator-unity-build-issues/15634/4 "2026-05-10T20:54:39Z")
@Eduard_Voronkin Great, thank you!
---
### Author:  [@kamchatka-volcano](https://discourse.cmake.org/u/kamchatka-volcano)
#### Post date: [May 18, 2026, 6:02pm UTC](https://discourse.cmake.org/t/fastbuild-generator-unity-build-issues/15634/5 "2026-05-18T18:02:02Z")
> However, in our project, version 4.2 is surprisingly much more performant (20–30% faster).
@Eduard_Voronkin
Hi, I just wanted to say that this was a false report. For some reason, the CMake clean target with FASTBuild doesn’t fully clean the project, and it affected my comparison. I retested it, ensuring a clean rebuild by deleting the build directory, and didn’t notice a significant difference in build times between versions 4.2 and 4.3. So for me, using the batching logic from the previous version is not important anymore.