CMake: Disable unity builds project-wide

[dextercd]

I have a project that uses xz via CMake's FetchContent module. This basically downloads xz and makes it part of the parent project using add_subdirectory.

After adding xz like this, I could no longer compile my project as a unity build because xz doesn't appear to support this. xz could certainly be modified to support this type of build, but that's not simply a one-time fix but a long term commitment.

These are the types of errors it generates:

In file included from /home/dexter/src/xz/src/liblzma/common/alone_decoder.c:14,
                 from /tmp/xz/CMakeFiles/liblzma.dir/Unity/unity_0_c.c:133:
/home/dexter/src/xz/src/liblzma/lz/lz_decoder.h:75:3: error: conflicting types for ‘lzma_lz_options’; have ‘struct <anonymous>’
   75 | } lzma_lz_options;
      |   ^~~~~~~~~~~~~~~
In file included from /home/dexter/src/xz/src/liblzma/lzma/lzma_encoder_private.h:16,
                 from /home/dexter/src/xz/src/liblzma/lzma/lzma_encoder.c:14:
/home/dexter/src/xz/src/liblzma/lz/lz_encoder.h:172:3: note: previous declaration of ‘lzma_lz_options’ with type ‘lzma_lz_options’
  172 | } lzma_lz_options;
      |   ^~~~~~~~~~~~~~~

/home/dexter/src/xz/src/xz/file_io.h:40:3: error: conflicting types for ‘io_buf’; have ‘union <anonymous>’
   40 | } io_buf;
      |   ^~~~~~
/home/dexter/src/xz/src/xz/file_io.h:40:3: note: previous declaration of ‘io_buf’ with type ‘io_buf’
   40 | } io_buf;
      |   ^~~~~~

This PR disables unity builds for the entire xz project directory. Because of how variable scoping works, if someone includes xz in their project and enables unity builds then it's still applied to any other part of the build that doesn't explicitly disable it for themselves.

Disabling unity builds when it doesn't work is recommended as per the UNITY_BUILD target property documentation:

Projects should not directly set the UNITY_BUILD property or its associated CMAKE_UNITY_BUILD variable to true. [...] However, it IS recommended to set the UNITY_BUILD property to false if it is known that enabling unity builds for target can lead to problems.

---

Unity builds can sometimes reveal UB as compilation errors because the compiler can suddenly analyse across what would normally be separate compilation units. I just want to make it abundantly clear that I DON'T think that's what is going on here.

xz just employs some code patterns that happen to be incompatible with unity builds.

[Larhzu]

Thanks! I had read about unity builds in Meson but I hadn't noticed that CMake supports them too. In the early days, some things were written with the assumption that compilers don't see between translation units. I learned the mistake later, and some things were fixed to make -flto work (likely those were "undefined behavior" issues). As you noticed, the way #includes currently work and the reuse of struct and static function names means that unity build won't work soon. Since you use CMake, I trust you have noticed the CMake changes in master vs. v5.6 like how most configuration options were renamed.

[thesamesam]

Thanks, this looks good to me as well.

[dextercd]

Thanks for merging! I hadn't looked at the differences in v5.6 vs. master. I've only been playing with the master branch for the moment.

[Larhzu]

No worries then. :) The master branch should be much nicer in terms of CMake support. I just don't want to backport it to v5.6 because some CMake changes depend on the changes to the C code too.