<feed xmlns='http://www.w3.org/2005/Atom'>
<title>puzzles/guess.R, branch master</title>
<subtitle>My sgt-puzzles tree</subtitle>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/'/>
<entry>
<title>Migrate to a CMake-based build system.</title>
<updated>2021-03-29T18:02:23+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2021-03-29T17:23:11+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=cc7f5503dc8f4ddf468e080a73028c83d1196e83'/>
<id>cc7f5503dc8f4ddf468e080a73028c83d1196e83</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Put the game summaries from the website into gamedesc.txt.</title>
<updated>2015-01-13T19:54:46+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2015-01-13T19:54:46+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=e3a8e64812f2fa783dc5644f04f267a291bc6098'/>
<id>e3a8e64812f2fa783dc5644f04f267a291bc6098</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Add a mechanism to the automake system to allow 'make install' to only</title>
<updated>2013-06-30T10:16:57+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2013-06-30T10:16:57+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=c06792c07609eacf6db0881f62a3391547c77248'/>
<id>c06792c07609eacf6db0881f62a3391547c77248</id>
<content type='text'>
install the actual games, not the auxiliary binaries or nullgame.

[originally from svn r9887]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
install the actual games, not the auxiliary binaries or nullgame.

[originally from svn r9887]
</pre>
</div>
</content>
</entry>
<entry>
<title>Rename wingames.lst to gamedesc.txt, and add a couple of extra fields</title>
<updated>2013-06-08T16:29:15+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2013-06-08T16:29:15+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=5dda5cf1d039767c632fe5e58ed7b95f5a615c0f'/>
<id>5dda5cf1d039767c632fe5e58ed7b95f5a615c0f</id>
<content type='text'>
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]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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]
</pre>
</div>
</content>
</entry>
<entry>
<title>Change to the handling of -DCOMBINED in the makefiles. Instead of</title>
<updated>2008-09-13T19:17:26+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2008-09-13T19:17:26+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=43eafe1fdf356c0c1c88936ffa79c83291973b5d'/>
<id>43eafe1fdf356c0c1c88936ffa79c83291973b5d</id>
<content type='text'>
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]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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]
</pre>
</div>
</content>
</entry>
<entry>
<title>Create a blank .rc file to be used in the absence of icons/foo.rc.</title>
<updated>2007-02-27T20:49:40+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2007-02-27T20:49:40+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=1dc3ce6d90c75f1a6b2e19cdaf5a3c0f92aaac05'/>
<id>1dc3ce6d90c75f1a6b2e19cdaf5a3c0f92aaac05</id>
<content type='text'>
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]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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]
</pre>
</div>
</content>
</entry>
<entry>
<title>Build an installer for Puzzles.</title>
<updated>2007-02-24T19:33:38+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2007-02-24T19:33:38+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=b05cb1eaf37d9ffd2dad7e335c344b2455d9f1e2'/>
<id>b05cb1eaf37d9ffd2dad7e335c344b2455d9f1e2</id>
<content type='text'>
[originally from svn r7319]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[originally from svn r7319]
</pre>
</div>
</content>
</entry>
<entry>
<title>Build script for Puzzles using bob. I've also added a piece of extra</title>
<updated>2007-02-04T11:44:10+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2007-02-04T11:44:10+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=dd1cee7537c05830475a15dd26ef8bc777738bba'/>
<id>dd1cee7537c05830475a15dd26ef8bc777738bba</id>
<content type='text'>
infrastructure to the mkfiles.pl framework for the convenience of
the build script: it generates `wingames.lst', a list of the Windows
binaries which are ship-worthy games as opposed to nullgame or
command-line auxiliary programs.

[originally from svn r7206]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
infrastructure to the mkfiles.pl framework for the convenience of
the build script: it generates `wingames.lst', a list of the Windows
binaries which are ship-worthy games as opposed to nullgame or
command-line auxiliary programs.

[originally from svn r7206]
</pre>
</div>
</content>
</entry>
<entry>
<title>Support for run-time icons in the GTK puzzles. This involved another</title>
<updated>2006-12-27T15:10:59+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2006-12-27T15:10:59+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=61b983ae3a8b1dc9033f7ef843a4a17228a8f311'/>
<id>61b983ae3a8b1dc9033f7ef843a4a17228a8f311</id>
<content type='text'>
mkfiles.pl change (I don't seem to be planning ahead very well this
week), this time to provide a list of fallback options for an object
file. That way, I have a no-icon.c which quietly replaces
icons/foo-icon.c if the latter doesn't exist, and so again people
checking straight out from Subversion shouldn't have trouble.

[originally from svn r7021]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
mkfiles.pl change (I don't seem to be planning ahead very well this
week), this time to provide a list of fallback options for an object
file. That way, I have a no-icon.c which quietly replaces
icons/foo-icon.c if the latter doesn't exist, and so again people
checking straight out from Subversion shouldn't have trouble.

[originally from svn r7021]
</pre>
</div>
</content>
</entry>
<entry>
<title>Actually introduce the ability to build the Windows icons into the</title>
<updated>2006-12-27T11:05:20+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2006-12-27T11:05:20+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=be8076a6e66cb4a2ac911eb65712b669f6df509a'/>
<id>be8076a6e66cb4a2ac911eb65712b669f6df509a</id>
<content type='text'>
Windows puzzle binaries. This checkin involves several distinct
changes:
 - mkfiles.pl now has an extra feature: if an object file is listed
   in Recipe with a trailing question mark, it will be considered
   optional, and silently dropped from the makefile if its primary
   source file isn't present at the time mkfiles.pl runs. This means
   people who check out the puzzles from Subversion and just run
   mkfiles.pl shouldn't get build failures; they just won't get the
   icons.
 - all the .R files now use this feature to include an optional
   Windows resource file.
 - the .rc resource source files are built by icons/Makefile.
 - windows.c finds the icon if present and uses it in place of the
   standard Windows application icon.

[originally from svn r7020]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Windows puzzle binaries. This checkin involves several distinct
changes:
 - mkfiles.pl now has an extra feature: if an object file is listed
   in Recipe with a trailing question mark, it will be considered
   optional, and silently dropped from the makefile if its primary
   source file isn't present at the time mkfiles.pl runs. This means
   people who check out the puzzles from Subversion and just run
   mkfiles.pl shouldn't get build failures; they just won't get the
   icons.
 - all the .R files now use this feature to include an optional
   Windows resource file.
 - the .rc resource source files are built by icons/Makefile.
 - windows.c finds the icon if present and uses it in place of the
   standard Windows application icon.

[originally from svn r7020]
</pre>
</div>
</content>
</entry>
</feed>
