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.
This is a technique I've had on the todo list (and been using by hand) for years: a domino can't be placed if it would divide the remaining area of the grid into pieces containing an odd number of squares. The findloop subsystem is already well set up for finding domino placements that would divide the grid, and the new is_bridge query function can now tell me the sizes of the area on each side of the bridge, which makes it trivial to implement this deduction by simply running findloop and iterating over the output array.
This technique borrows its name from the Solo / Map deduction in which you find a path of vertices in your graph each of which has two possible values, such that a choice for one end vertex of the chain forces everything along it. In Dominosa, an approximate analogue is a path of squares each of which has only two possible domino placements remaining, and it has the extra-useful property that it's bidirectional - once you've identified such a path, either all the odd domino placements along it must be right, or all the even ones. So if you can find an inconsistency in either set, you can rule out the whole lot and settle on the other set. Having done that basic analysis (which turns out to be surprisingly easy with an edsf to help), there are multiple ways you can actually rule out one of the same-parity chains. One is if the same domino would have to appear twice in it; another is if the set of dominoes that the chain would place would rule out all the choices for some completely different square. There are probably others too, but those are the ones I've implemented.
I've made the existing optional solver diagnostics appear as the verbose output of the solver program. They're not particularly legible at the moment, but they're better than nothing.
More sensible to bring all the pieces of per-puzzle descriptive text together into one place, so they can be easily reused everywhere they're needed.
install the actual games, not the auxiliary binaries or nullgame. [originally from svn r9887]
to it giving each game's "internal" name (as seen in the source file, .R etc) and also a brief description of the game. The idea of the latter is that it should be usable as a comment field in .desktop files and similar. [originally from svn r9858]
randomly generates a tiling of a rectangle with dominoes, since he wants to reuse that function in another puzzle. [originally from svn r8488]
defining it centrally per port, I think it's neater to define it for each puzzle when adding that puzzle to the ALL list - because those front ends which take -DCOMBINED are precisely those which use ALL. In particular, this change opens up the possibility of compiling both individual puzzles _and_ a combined monolith within the same makefile. [originally from svn r8178]
This means that puzzles.rc2 is always included in all Windows and PocketPC builds, which in turn means that I should be able to start filling it full of VERSIONINFO and have that reliably included as well. [originally from svn r7339]