ref: 1611a5e058204c5ab4cd2ac29d2d3f7a2184d35d
parent: b967a3ea86d6285457abc2a89e455c8f62d2c22a
author: Ben Harris <bjh21@bjh21.me.uk>
date: Tue Nov 29 16:13:52 EST 2022
Developer doc correction: list.c is not generated by Perl any more
--- a/devel.but
+++ b/devel.but
@@ -33,7 +33,7 @@
new platform.
This guide is believed correct as of \cw{git} commit
-\cw{c6e312b252bc41eac10dff60f1c6675c762b4cee}. Hopefully it will be
+\cw{b967a3ea86d6285457abc2a89e455c8f62d2c22a}. Hopefully it will be
updated along with the code in future, but if not, I've at least left
this version number in here so you can figure out what's changed by
tracking commit comments from there onwards.
@@ -191,9 +191,8 @@
\b On platforms such as MacOS X and PalmOS, which build all the
puzzles into a single monolithic binary, the game structure in each
back end must have a different name, and there's a helper module
-\c{list.c} (constructed automatically by the same Perl script that
-builds the \cw{Makefile}s) which contains a complete list of those
-game structures.
+\c{list.c} which constructs a complete list of those game structures
+from a header file generated by CMake.
On the latter type of platform, source files may assume that the
preprocessor symbol \c{COMBINED} has been defined. Thus, the usual