VS: Inconsistent conditions for `EnableUnitySupport` and `CustomUnityFile` MSBuild properties
Hello,
We use CMake with proprietary platforms where I work and an issue appeared recently with one of this platform. From my investigation, I think there might be an issue in CMake in regards to the detection of the support for native Unity builds in Visual Studio.
The target generator (cmVisualStudio10TargetGenerator.cxx
) checks at two places whether the active generator supports Unity builds, one to set the EnableUnitySupport
property (see https://gitlab.kitware.com/cmake/cmake/-/blob/eb6e2ef7f61de1dd4ff6ec39e886d5fa8cf9aea7/Source/cmVisualStudio10TargetGenerator.cxx#L2432) and one to set the CustomUnityFile
property, and a few others (see https://gitlab.kitware.com/cmake/cmake/-/blob/eb6e2ef7f61de1dd4ff6ec39e886d5fa8cf9aea7/Source/cmVisualStudio10TargetGenerator.cxx#L2561). The issue is that the later also checks the toolset version (141
and later), as such, if the toolset is custom, native Unity support is enabled through EnableUnitySupport
, but custom Unity files generated by CMake are not annotated, which may cause unexpected side effects.
I'm not sure if the toolset version check should remain or if the call to GetSupportsUnityBuilds()
is enough. I'm less aware on how the VCTargets are loaded when targeting an older toolset from a newer Visual Studio instance, so maybe that's what this check was about. If that's the case, EnableUnitySupport
should be behind the same check to ensure consistency (but it would be good to have some way to teach CMake that X toolset also supports the native integration). Otherwise, maybe the toolset version check can be dropped.
Note. This can be reproduced by using LLVM with Visual Studio 2019 as the toolset will be LLVM
and not the vNNN
format expected to detect whether to use the additional properties like CustomUnityFile
. The vcxproj
will have inconsistent properties (although I didn't had compilation issues like I did with the proprietary platform).