DaemonEngine
cmake: unify GCC, Clang and PNaCl compiler configuration
- unify GCC, Clang and PNaCl compiler configuration
- pass more build options to the sub-cmake game build
- always set C standard, it will be required for building zlib with Saigo or Wasi
- add options to not enforce C/C++ standards
- move the target specific build options to another if/else block
Now PNaCl uses the same configuration as GCC and Clang, avoids discrepancies like this to be introduced:
- https://github.com/DaemonEngine/Daemon/pull/1160
This also make possible to pass build options like LTO to the sub-cmake game call. I'm not sure it really does something with PNaCl as the produced files are the same size (and LTO usually makes our binaries much smaller), but the compiler accepts the option so, it's not bad to pass it. It will be ready for other compilers like Saigo or Wasi.
The C standard is now always enforced, it was required for NaCl because NaCl uses some in-tree zlib source. It makes possible to use an in-tree zlib for things other than PNaCl, something we would want for Saigo or Wasi. And if we ship an own zlib, there is no reason to not build the engine against it. The usage or the in-tree zlib for every binary is not part of that PR, but this PR makes the CMake code ready for it.
Also, for debugging purpose, one can disable the C/C++ standard enforcement with advanced USE_RECOMMENDED_C_STANDARD and USE_RECOMMENDED_CXX_STANDARD variables.
I forgot to mention it, but this also makes explicit the optimization level used for the selected build profile. In the future I plan to make RelWithDebInfo use -O3 so everything will be there to just flip the number. For releases we currently use RelWithDebInfo with default -O2:
- https://github.com/DaemonEngine/Daemon/issues/507
I forgot to mention it, but this also makes explicit the optimization level used for the selected build profile.
Well, this is probably a bad idea, even if someday we override them.
The reason why I went this way was because the NaCl code path as doing it, so when I unified it with other compilers, I thought “why not?”. It happens the NaCl code path doing it is a workaround for CMake failing to detect that PNaCl is a clang-compatible compiler. We better want to rely on extensive compiler detection as implemented in #982 to set the fallbacks for every clang-compatible compiler we detect:
- https://github.com/DaemonEngine/Daemon/pull/982
So for now I'll revert the unconditional setting of compiler optimizations and keep the if (NACL) workaround until we can rely on something more generic thanks to #982.
Why should there be an option not to use the appropriate language standard? I don't get it. Maybe it was useful one time, but not everything needs to be a checkbox option, if someone needs to do something really obscure they can edit the build system.
Why should there be an option not to use the appropriate language standard?
Generic answer: I like knobs.
Specific answers:
- It makes easier for testing other standards without the default ones getting in the way, so it could be useful as a debug tool the day we raise the standards.
- It also makes easy to test the build without those flags, I remember that when I toyed with Android at first it was failing to build with the flags but the without it built. Finding the root cause of why it didn't built with the flag was a specific task that was a different task than testing the rest of the code.
- Not all the code base require those standards. For example C++14 isn't required to build a working game server, C++11 is enough.
- I really like to be able to disable stuff for testing and debugging purpose in general, and I had to comment out those lines at least three times in the recent years for testing purpose, and editing code breaks rebasing and other things.
Having a knob that makes the program fail to build kinda sucks. But on the other hand, it sucks that there is often no way to disable all the flags added by our build system, like you could with something like CXXGLAGS='' in a simpler build system. So I can see the utility of having a way to knock out some flags. :+1:
I moved the setting of PNaCl default build flag to the PNaCl toolchain itself. It makes much sense like that. I haven't set the -O0 for debug as it is not what CMake does for other clang-based compilers:
- https://github.com/Unvanquished/Unvanquished/pull/3043