cmake: make DaemonPlatform, Architecture, Compiler, etc. autonomous and reusable

[illwieckz]

Some revamp of the DaemonPlatform/DaemonArchitecture/DaemonCompiler/DaemonBuildInfo helper code for CMake.

I want this framework to be reusable for other projects, the first user outside of the engine may be the NaCl loader itself, and I may use it for NetRadiant as well at some point. So I made the code fully autonomous and contained in a single folder (so it can be copied and kept it sync easily).

It happens that the endian stuff we did in the DaemonCompiler code using Endian.h was useless (it was not doing better than what the qprocessordetection.h code does anyway), so I removed it.

I also renamed GAME_PIE to NACL_PIE because it's an NaCl option, it was named GAME_PIE because we only build games as NaCl, but for a self-contained framework we better name the NaCl option NACL. For now this code sets GAME_PIE to the NACL_PIE value but once the game is modified to use NACL_PIE the code setting the GAME_PIE alias will be deleted.

[slipher]

Why would we need a variable called NACL_PIE? There is no PIE for NaCl and never will be.

[slipher]

I want this framework to be reusable for other projects

Note that some of the facilities here duplicate CMake built-in functionality, or have more fully developed alternatives available from other projects. Effort is likely to be wasted in such cases:

• For daemon_write_generated(file.cpp ${contents}), CMake's file(GENERATED OUTPUT file.cpp CONTENTS ${contents}) is a drop-in replacement, modulo daemon_write_generated adding stuff to the path name. See the slipher/cmake-filegenerated branch.
• The build info stuff largely duplicates the functionality of CMake's configure_file.
• For a platform-independent resource compiler implemented as CMake script / embedding files (though that's not actually part of this PR currently), there is https://github.com/vector-of-bool/cmrc

DaemonArchitecture looks most likely to be useful. I think I saw a similar thing with SDL, but Daemon's looked more complete.

[slipher]

Why would we need a variable called NACL_PIE? There is no PIE for NaCl and never will be.

Well maybe I'm wrong about that: the native_client scons build has a nacl_pic option. It has an effect only for PNaCl toolchains, not Saigo.

[slipher]

Then again, there is a comment explaining that it is not useful:

# Since PNaCl has no reason to generate PIC at all until there is some
# form of ELF shared object support (if that ever happens at all),
# perhaps we'll never really need to test this.

Also there is another comment confirming that Saigo does not have PIC.

[illwieckz]

I removed the unused NaCl PIE thing.

[slipher]

Why do we need this file? Are some of the files dependent on each other and so have to be included in a specific order?

[illwieckz]

We need to include them in specific order, and the Compiler stuff (and maybe other things) are writing constants (like compiler name and version) that is generated as source with SourceGenerator to be embedded in the binary.

[illwieckz]

Also Architecture requires System to be included first so it can select amd64 as NACL_ARCH on arm64 macOS, and things like that.

[slipher]

Could we use this instead? https://cmake.org/cmake/help/v3.17/command/include_guard.html
Then each file can include its own dependencies and the user does not need to take care to call them in a special order.

[illwieckz]

You'll end up loading them anyway.

The only thing that seems to be interesting to do is to provide an option to not generate the source files with the various discovered things, for projects not caring about reporting the build environment to the user. For example we don't need such reporting in NaCl.

[illwieckz]

With the latest version, if you only include Detection.cmake without having included SourceGenerator.cmake first (or the Platform.cmake entry point which is meant to include everything supported), then no source is generated when detecting the build environment.

[illwieckz]

I landed my rewrite of System.cmake that does like Compiler.cmake to detect the target system.

This defines variables like DAEMON_HOST_SYSTEM and DAEMON_TARGET_SYSTEM.

A good example of usage of them is to avoid the ambiguity of WIN32.

Instead of WIN32 to detect the target we can use DAEMON_TARGET_SYSTEM_Windows and instead of MSVC and NOT MSVC AND WIN32 to detect the compiler we can use DAEMON_CXX_COMPILER_MSVC and DAEMON_CXX_COMPILER_MinGW.

It may also help to do things differently with MinGW on Linux and MinGW on Windows, when needed.

It may also help in the future as cross-compiler evolves, for example the day Zig becomes suitable for us to cross-compile for macOS on Linux, and things like that.

I also renamed ARCH and NACL_ARCH as DAEMON_ARCH and DAEMON_NACL_ARCH, as I prefer those global variable to be prefixed with DAEMON, especially since I write that DamonPlatform things to be reusable outside of the engine, and short names like ARCH are likely to collide.

[illwieckz]

I also landed my mutualisation of Architecture/Compiler/System detection, all of them now using the same syntax in the C detection source file, and now using the same function to extract the data from the compilation log.

[illwieckz]

There is now a unique DaemonPlatform/Detection/detect script that can be used to test the compilation-based detection outside of CMake:

$ ./detect clang
DAEMON_COMPILER_GCC_COMPATIBILITY=ON
DAEMON_COMPILER_GCC_VERSION=4.2.1
DAEMON_COMPILER_Clang_COMPATIBILITY=ON
DAEMON_COMPILER_Clang_VERSION=18.1.3
DAEMON_COMPILER_Clang_VERSION_STRING=18.1.3 (1ubuntu1)
DAEMON_COMPILER_generic_VERSION_STRING=Ubuntu Clang 18.1.3 (1ubuntu1)
DAEMON_COMPILER_NAME=Clang
DAEMON_SYSTEM_Linux_COMPATIBILITY=ON
DAEMON_SYSTEM_Unix_COMPATIBILITY=ON
DAEMON_SYSTEM_NAME=Linux
DAEMON_ARCH_NAME=amd64

$ ./detect i686-w64-mingw32-gcc
DAEMON_COMPILER_GCC_COMPATIBILITY=ON
DAEMON_COMPILER_GCC_VERSION=13.0.0
DAEMON_COMPILER_generic_VERSION_STRING=13-posix
DAEMON_COMPILER_NAME=MinGW
DAEMON_SYSTEM_NAME=Windows
DAEMON_ARCH_NAME=i686

$ ./detect arm-nacl-clang
DAEMON_COMPILER_GCC_COMPATIBILITY=ON
DAEMON_COMPILER_GCC_VERSION=4.2.1
DAEMON_COMPILER_Clang_COMPATIBILITY=ON
DAEMON_COMPILER_Clang_VERSION=21.0.0
DAEMON_COMPILER_Clang_VERSION_STRING=21.0.0git (https://chromium.googlesource.com/native_client/nacl-llvm-project-v10.git 9c7f0369cfdd591e580c5ccfc1f00fedee58029f)
DAEMON_COMPILER_generic_VERSION_STRING=Clang 21.0.0git (https://chromium.googlesource.com/native_client/nacl-llvm-project-v10.git 9c7f0369cfdd591e580c5ccfc1f00fedee58029f)
DAEMON_COMPILER_NAME=Saigo
DAEMON_SYSTEM_Unix_COMPATIBILITY=ON
DAEMON_SYSTEM_NAME=NaCl
DAEMON_ARCH_NAME=nacl

[illwieckz]

Actually I noticed that we can report the native architecture built with Saigo (since Saigo does direct-to-nexe):

$ ./detect pnacl-clang
DAEMON_COMPILER_GCC_COMPATIBILITY=ON
DAEMON_COMPILER_GCC_VERSION=4.2.1
DAEMON_COMPILER_Clang_COMPATIBILITY=ON
DAEMON_COMPILER_Clang_VERSION=3.6.0
DAEMON_COMPILER_Clang_VERSION_STRING=3.6.0 (https://chromium.googlesource.com/a/native_client/pnacl-clang.git 96b3da27dcefc9d152e51cf54280989b2206d789) (https://chromium.googlesource.com/a/native_client/pnacl-llvm.git d0089f0b008e03cfd141f05c80e3b628c2df75c1)
DAEMON_COMPILER_generic_VERSION_STRING=4.2.1 Compatible Clang 3.6.0 (https://chromium.googlesource.com/a/native_client/pnacl-clang.git 96b3da27dcefc9d152e51cf54280989b2206d789) (https://chromium.googlesource.com/a/native_client/pnacl-llvm.git d0089f0b008e03cfd141f05c80e3b628c2df75c1)
DAEMON_COMPILER_NAME=PNaCl
DAEMON_SYSTEM_Unix_COMPATIBILITY=ON
DAEMON_SYSTEM_NAME=NaCl
DAEMON_ARCH_NAME=pnacl

$ ./detect arm-nacl-clang
DAEMON_COMPILER_GCC_COMPATIBILITY=ON
DAEMON_COMPILER_GCC_VERSION=4.2.1
DAEMON_COMPILER_Clang_COMPATIBILITY=ON
DAEMON_COMPILER_Clang_VERSION=21.0.0
DAEMON_COMPILER_Clang_VERSION_STRING=21.0.0git (https://chromium.googlesource.com/native_client/nacl-llvm-project-v10.git 9c7f0369cfdd591e580c5ccfc1f00fedee58029f)
DAEMON_COMPILER_generic_VERSION_STRING=Clang 21.0.0git (https://chromium.googlesource.com/native_client/nacl-llvm-project-v10.git 9c7f0369cfdd591e580c5ccfc1f00fedee58029f)
DAEMON_COMPILER_NAME=Saigo
DAEMON_SYSTEM_Unix_COMPATIBILITY=ON
DAEMON_SYSTEM_NAME=NaCl
DAEMON_ARCH_NAME=armhf

$ ./detect i686-nacl-clang
DAEMON_COMPILER_GCC_COMPATIBILITY=ON
DAEMON_COMPILER_GCC_VERSION=4.2.1
DAEMON_COMPILER_Clang_COMPATIBILITY=ON
DAEMON_COMPILER_Clang_VERSION=21.0.0
DAEMON_COMPILER_Clang_VERSION_STRING=21.0.0git (https://chromium.googlesource.com/native_client/nacl-llvm-project-v10.git 9c7f0369cfdd591e580c5ccfc1f00fedee58029f)
DAEMON_COMPILER_generic_VERSION_STRING=Clang 21.0.0git (https://chromium.googlesource.com/native_client/nacl-llvm-project-v10.git 9c7f0369cfdd591e580c5ccfc1f00fedee58029f)
DAEMON_COMPILER_NAME=Saigo
DAEMON_SYSTEM_Unix_COMPATIBILITY=ON
DAEMON_SYSTEM_NAME=NaCl
DAEMON_ARCH_NAME=i686

$ ./detect x86_64-nacl-clang
DAEMON_COMPILER_GCC_COMPATIBILITY=ON
DAEMON_COMPILER_GCC_VERSION=4.2.1
DAEMON_COMPILER_Clang_COMPATIBILITY=ON
DAEMON_COMPILER_Clang_VERSION=21.0.0
DAEMON_COMPILER_Clang_VERSION_STRING=21.0.0git (https://chromium.googlesource.com/native_client/nacl-llvm-project-v10.git 9c7f0369cfdd591e580c5ccfc1f00fedee58029f)
DAEMON_COMPILER_generic_VERSION_STRING=Clang 21.0.0git (https://chromium.googlesource.com/native_client/nacl-llvm-project-v10.git 9c7f0369cfdd591e580c5ccfc1f00fedee58029f)
DAEMON_COMPILER_NAME=Saigo
DAEMON_SYSTEM_Unix_COMPATIBILITY=ON
DAEMON_SYSTEM_NAME=NaCl
DAEMON_ARCH_NAME=amd64