Replacing scons and qmake

[ryandesign]

Clock Signal currently has three build systems: Xcode for the macOS/Metal UI, scons for the SDL/OpenGL UI, and qmake for the Qt/OpenGL UI. Maintaining multiple build systems is duplicated labor and can lead to unintended discrepancies between the build systems when a change is made in one but not the others (like the color problem I fixed in #1270), so I want to gauge your interest in replacing the scons and qmake build systems with something like cmake. scons has always been a frustrating build system for me wherever I've encountered it, and the Qt developers themselves have moved on from qmake to cmake, leading many qmake-based projects to do the same. A single cmake build system should be able to accommodate building for either SDL or Qt with a user-selectable switch. It could even handle building the Mac version, should that be desirable.

[TomHarte]

I'm not a fan of CMake for most idiomatically having boilerplate CMakeFiles.txt files everywhere, but also:

• if you're going to pick fault, all the build systems are problematic in one way or another; and
• Qt does appear genuinely to be in transition, so better to try to keep up.

It also helps to resolve some of this project's ongoing Snapcraft issues, as QMake isn't well supported at or beyond core20. Though Qt isn't well supported in general, so the Snap question would remain dangling.

Separately, it would be nice to reorganise the repository just a little so that all source code-type files are bundled away in a 'source' directory or similar underneath the top level. Besides being a somewhat more standard layout, it'd make it explicit that ROMImages, READMEImages, OSBinding and .github aren't inherently related to the build.

[ryandesign]

I build a lot of CMake-based projects in my role as a maintainer of ports in MacPorts and have used CMake as the build system for one of my own projects, so I have a little familiarity with it and would be happy to try to write a CMake build system for Clock Signal. I just didn't want to start work on it if you were completely against the idea.

I 100% agree that all build systems are terrible each in their own way. What CMake has going for it is that it is very popular and has extensive documentation. If you encounter some problem with CMake, someone else will have encountered it before and will have a solution or workaround.

What's particularly terrible about SCons, in my opinion, is its design decision to ignore the user's environment variables. This led to numerous problems for me trying to build Clock Signal, only one of which I fixed in 2352b4e. I wanted to avoid flooding you with other bug reports about the SCons build system if I could convince you to switch to CMake which doesn't have this particular set of problems.

Another SCons problem is that the SConstruct file is a Python script. Over the years I've encountered numerous projects whose SConstruct files didn't work anymore after the version of Python used for SCons was changed. CMake in contrast uses its own syntax for its CMakeLists.txt files which in my experience has not been prone to breakage due to upgrading the CMake version.

It's true that CMake usually has a CMakeLists.txt file in each directory, which I found fairly helpful in my project due to the way the directory structure was organized—admittedly a structure directly influenced by the fact that I decided to use CMake from the beginning. I don't think this is a hard requirement however and with the way that your source files are spread out into numerous directories I would want to avoid putting a CMakeLists.txt into each of them. Moving all your source files into a common top-level directory is not a bad idea but needn't be part of this if you're not ready for that yet.

If you're ok with me beginning to work on a CMake build system for Clock Signal I'd start with the goal of replacing the SCons build system for the SDL version. Replacing the QMake build system for the Qt version would be a second phase.

[TomHarte]

Yeah, if you're willing to donate your time to taking a run at it then I'd definitely be grateful. Build systems in general have never been my forte.

That said, it's been CMake at both of my recent employers so I'm not blind to the way the wind is blowing.

[ryandesign]

It's not ready to submit yet, but I did just get my first successful build of the SDL version on macOS with CMake (and with just one CMakeLists.txt!).

[TomHarte]

Fantastic, thanks so much! I'm going to be away from the computer for about a week starting late tomorrow so I apologise that I'm about to go quiet, but I think this'll be a big step forwards.

Oh, also, I probably forgot to say: the plan is unambiguously to switch to idiomatic project-relative #includes rather than the weird file-relative ones currently in use, but I've never quite got around to working through it. So sorry if that strangeness is causing any issues.

[ryandesign]

Ok! I may be busy during February so I cleaned up what I have so far and submitted it in #1324.