CMake ファイルの改善

[Reputeless]

• https://app.slack.com/client/T03MVATHL/C01KDGT4EH5
• https://github.com/MurakamiShun/OpenSiv3D/tree/refine_cmake
• by @MurakamiShun

[KingDuckZ]

Following my attempt at fixing the build, I tried re-writing the build script with meson (it could be cmake, no big difference in the outcome imo). I got into a rabbit hole because things kept breaking. So far I encountered these major issues:

• boost geometry doesn't compile - my systems has boost 1.78 and the bundled boost geometry doesn't compile against that. I updated it to latest (upstream build is broken, see my patch below) and got past this issue
• plenty of linker errors - directory Siv3D/src/ThirdParty has source files taken from several external projects; these files are compiled manually into the main Siv3D library. I don't see the reason for removing the upstream build scripts, so I removed some directories from "ThirdParty" (geometry, glfw, lunasvg, minizip) and added them as subprojects to get past this error. This also had the nice side effect of removing clutter from Siv3D's build script
• custom patches to external projects - the external projects I removed had some modifications to them. Specifically, glfw has edits such as _glfw.ns.keycodes[0x5E] = SIV3D_KEY_JIS_UNDERSCORE;. I think those should be contributed back into upstream and Siv3D should refer to a custom fork until the patch gets accepted. If glfw refuses to merge that, for whatever reason, then Siv3D should keep a custom fork that's updated regularly. Note that there are several techniques to achieve this.

Patch for boost geometry:

diff --git a/include/boost/geometry/extensions/algorithms/dissolve.hpp b/include/boost/geometry/extensions/algorithms/dissolve.hpp
index 958cf7c25..7fe571944 100644
--- a/include/boost/geometry/extensions/algorithms/dissolve.hpp
+++ b/include/boost/geometry/extensions/algorithms/dissolve.hpp
@@ -414,12 +414,12 @@ struct dissolve
     template
     <
         typename Geometry, typename RescalePolicy, typename OutputIterator,
-        typename Strategy, typename Visitor
+        typename Strategy2, typename Visitor
     >
     static inline OutputIterator apply(Geometry const& geometry,
                                        RescalePolicy const& rescale_policy,
                                        OutputIterator out,
-                                       Strategy const& strategy,
+                                       Strategy2 const& strategy,
                                        Visitor& visitor)
     {
         return dispatch::dissolve
@@ -440,12 +440,12 @@ struct dissolve<GeometryOut, Strategy, false>
     template
     <
         typename Geometry, typename RescalePolicy, typename OutputIterator,
-        typename Strategy, typename Visitor
+        typename Strategy2, typename Visitor
     >
     static inline OutputIterator apply(Geometry const& geometry,
                                        RescalePolicy const& rescale_policy,
                                        OutputIterator out,
-                                       Strategy const& strategy,
+                                       Strategy2 const& strategy,
                                        Visitor& visitor)
     {
         using strategies::relate::services::strategy_converter;

I gave up on getting the build fixed because it's a significant investment of time and, at this point, I'm not even sure Siv3D is the tool I need as I've not been able to use it yet. I can provide some help but it's not going to be painless. To summarise:

1. prefix all intrinsics with "simde", conditionally define SIMDE_ENABLE_NATIVE_ALIASES where necessary (maybe provide an option in meson/cmake to force it on/off?)
2. remove external source code from the repository
3. patch external projects as appropriate
4. after porting everything to nice, clean cmake or meson build scritpts, it could be possible to get rid of all system specific build files in macOS and WindowsDesktop directories, as well as binary files in "Siv3D/lib"

If you decide to stay with cmake, I suggest using ExternalProject to manage the dependencies. If you want to move to meson (I think it's cleaner and more modern) you could use its wrap system to achieve the same. Note that you don't need to port external cmake projects to meson. You can just use meson's cmake module. Alternatively, git submodule could be an option. In either case, I think this should be the logic for almost all dependencies:

1. optionally provide a build option to ask users if they want a certain feature, for example "opus" (see meson's "features" feature)
2. for custom patched external libraries such as glfw, use the bundled version
3. for standard, compulsory libraries, look up the system installed library first and fall back to the bundled version if not found (example with sqlite)
4. for standard, optional libraries, look up the system installed library or disable the feature if not found (potentially add a "use_bundled_x" build option to achieve a combination of points 3 and 4)
5. set a configuration entry to mark if that library was available or not (and optionally which version)

This should help making a robust build script that's easy for users to configure and for developers to updated. The aim is to enable the majority of users to just "use Siv3D" and let them customise which features they want effortlessly.