This completely removes the old system of mkfiles.pl + Recipe + .R
files that I used to manage the various per-platform makefiles and
other build scripts in this code base. In its place is a
CMakeLists.txt setup, which is still able to compile for Linux,
Windows, MacOS, NestedVM and Emscripten.
The main reason for doing this is because mkfiles.pl was a horrible
pile of unmaintainable cruft. It was hard to keep up to date (e.g.
didn't reliably support the latest Visual Studio project files); it
was so specific to me that nobody else could maintain it (or was even
interested in trying, and who can blame them?), and it wasn't even
easy to _use_ if you weren't me. And it didn't even produce very good
makefiles.
In fact I've been wanting to hurl mkfiles.pl in the bin for years, but
was blocked by CMake not quite being able to support my clang-cl based
system for cross-compiling for Windows on Linux. But CMake 3.20 was
released this month and fixes the last bug in that area (it had to do
with preprocessing of .rc files), so now I'm unblocked!
CMake is not perfect, but it's better at mkfiles.pl's job than
mkfiles.pl was, and it has the great advantage that lots of other
people already know about it.
Other advantages of the CMake system:
- Easier to build with. At least for the big three platforms, it's
possible to write down a list of build commands that's actually the
same everywhere ("cmake ." followed by "cmake --build ."). There's
endless scope for making your end-user cmake commands more fancy
than that, for various advantages, but very few people _have_ to.
- Less effort required to add a new puzzle. You just add a puzzle()
statement to the top-level CMakeLists.txt, instead of needing to
remember eight separate fiddly things to put in the .R file. (Look
at the reduction in CHECKLST.txt!)
- The 'unfinished' subdirectory is now _built_ unconditionally, even
if the things in it don't go into the 'make install' target. So
they won't bit-rot in future.
- Unix build: unified the old icons makefile with the main build, so
that each puzzle builds without an icon, runs to build its icon,
then relinks with it.
- Windows build: far easier to switch back and forth between debug
and release than with the old makefiles.
- MacOS build: CMake has its own .dmg generator, which is surely
better thought out than my ten-line bodge.
- net reduction in the number of lines of code in the code base. In
fact, that's still true _even_ if you don't count the deletion of
mkfiles.pl itself - that script didn't even have the virtue of
allowing everything else to be done exceptionally concisely.
To begin with, the toolchain no longer lets me build for x86-32 - apparently MacOS is now 64-bit only. Also, the linker now gives an error about a missing libgcc_s variant for -mmacosx-version-min=10.4, and indeed 10.5. So I've bumped the minimum supported OS version to 10.6. That in turn required some changes in osx.m itself, because bumping the min OS version caused some API deprecations to show up. Luckily I turned out to have left myself a comment some time ago telling me what I was going to need to do about one of them :-)
OS X is beginning to show a warning when a 32-bit application is opened, so it's high time that this gets enabled. Fix a clang warning exposed by this build.
I've built a set of 32-bit binaries, a 32-bit zip file and a 32-bit MSI, all delivered into a 'w32' output directory.
Mostly just cribbed from the corresponding changes in PuTTY's build setup, although since the two mkfile.pl scripts are not _quite_ identical, I had to make a few tweaks.
This is a combination of PuTTY r10142 and the relevant pieces of r10141: we now enable the 'subdir-objects' mode in Makefile.am, and stop using $(subdir) in source file paths. (As a consequence of the latter the automake machinery now cannot live anywhere but at the top level of the source tree, but since that's where it was already, this is less of an upheaval here than it was for PuTTY!) [originally from svn r10146] [r10141 == a947c49bec36957cb5d38e1dc2e22dc0e3465849 in putty repository] [r10142 == 0da225829234744b1141aea3a7c54ad7d74679a7 in putty repository]
revision number from being automatically baked into the automake-built binaries. [originally from svn r9890]
install the actual games, not the auxiliary binaries or nullgame. [originally from svn r9887]
Makefile.am, and there's a new mkauto.sh which builds a corresponding configure script. The old makefile has been renamed from 'Makefile' to 'Makefile.gtk', indicating that the intended new _default_ approach is to use the autoconf world. Makefile.gtk is provided as an emergency fallback in case anything fails with the new stuff that used to work with it. The new configure script does not support the same $(BINPREFIX) system as the old Makefile did. However, as I understand it, it should be possible to configure using --program-prefix="sgt-" (for example) and then the binaries should all be renamed appropriately at install time. The Makefile.am is quite painful. The Puzzles codebase relies heavily on compiling individual object files multiple times with different the cpp flags per build deliverable (program or library) and not per source file. Solution: anything built with non-default compile options has to go in its own little library. But that doesn't work either in the general case, because as soon as you have more than one such library linked into an application, Unix ld semantics bite you if the objects in the libraries both refer to each other. So I ended up building all those little libraries but not _using_ them - instead the link commands for the programs needing those objects refer to the objects directly, under the silly names that automake gives them. (That's less fragile than it sounds, because it does _document_ the names of the intermediate object files. But still, yuck.) [originally from svn r9886]
applets, here's an alternative webification in Javascript, using Emscripten in asm.js mode (so that as browsers incorporate asm.js optimisation, the game generation should run really fast). [originally from svn r9781]