Vega-strike-engine-source: Replace CMake with a alternative build system?

[stephengtuggy]

So. Last year, I literally spent two months tearing my hair out, trying to get CMake to work across Windows and Linux, and to get the stupid thing to actually build!

My takeaway? It just isn't worth it. CMake is not the build system it once was. We should probably consider other alternatives, just for ease of development, if nothing else.

One possibility is the Mozilla mach build system. Open to other ideas though.

Thanks guys!

[stephengtuggy]

Relates to #53

[nabaco]

Hi @stephengtuggy,
I have to say that I disagree with this notion. CMake works perfectly fine for me on all platforms and does its job quite well. It's not perfect, but from what I see, it's the best out there.
Furthermore, unlike mach, it's widely known and used and has a lot more features, including a GUI.

Regarding the windows compilation, the main issues I see there are dependency finding and building, and not the build system itself. In fact, CMake has all the facilities to overcome that, including the ability to download sources from the internet, and compile them locally as part of the build process.

If anything, I would say that we need to update and improve our CMakeLists.txt, so it'll accommodate to all of our needs.

[BenjamenMeyer]

There's little nits I have about CMake; but the biggest issue is that there really isn't another cross-platform build chain that is as capable and not tied to some specific project and the nuances of those projects. CMake has actually been growing in use among the FOSS community in the last few years with even Qt making it their official build system a couple years back; I believe KDE did the same too. (Note: Qt even wrote two of their own build systems - qmake and qbs.) There's a handful of others capable build systems other there, but most are tied to Java or a language we don't use and are not easy to integrate. I suspect mach will be tied to how Mozilla does stuff too (typical - see Bugzilla) since it's built for their particular use-case.

I do agree agree with @nabaco that the issue isn't likely Cmake itself; more likely it's how we use CMake and how we suppose those specific platforms.

1. We should break down the CMakeLists.txt to be more oriented around various targets and sub-targets. For example, any library should get split out into its own structure and included in. This will probably be done as part of the refactoring effort at some point.
2. We should detect what we need as much as possible, and if possible use the OS provided stuff. This will be particularly true on Linux. On Mac we might even be able to integrate HomeBrew support to pull stuff down and install it if needed - though it'd probably be better to just error out and tell the user to install something. On Windows, we could probably integrate Choco like HomeBrew, or we could just download some pre-built stuff out of GitHub Packages or a vendor site (likely try the vendor and fall back to GitHub Packages to save @Loki1950 's wallet). This can be achieved through enhancing functionality around the Find functions and what to do if something isn't found.

It'll take some effort to get there but all the tools are there that are needed.

Advantages of CMake:

• cross platform
• cross compiler chain
• will dump configurations for various IDEs if folks want to use them (XCode, VS, etc)
• tied to a vendor (Kitware) but not to a project. Kitware makes their money selling add-on services to CMake and their various other tools for integration across things.

[stephengtuggy]

Fair enough, guys. OK, I'm closing the issue.