<feed xmlns='http://www.w3.org/2005/Atom'>
<title>puzzles/icons/Makefile, 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>Create 96x96 icons for gnome-shell</title>
<updated>2018-01-21T19:03:38+00:00</updated>
<author>
<name>Adrian Heine</name>
<email>mail@adrianheine.de</email>
</author>
<published>2018-01-20T12:05:18+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=43b9eb1472d2a82e5369815511a9ae6681a61a08'/>
<id>43b9eb1472d2a82e5369815511a9ae6681a61a08</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Add a new puzzle: Palisade.</title>
<updated>2015-10-18T16:53:28+00:00</updated>
<author>
<name>Jonas Kölker</name>
<email>jonaskoelker@yahoo.com</email>
</author>
<published>2015-10-02T11:13:39+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=6860c65bb3807dd83830e047d35d8f0fe4e89a86'/>
<id>6860c65bb3807dd83830e047d35d8f0fe4e89a86</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Add '-set colorspace RGB' to some icon convert commands.</title>
<updated>2015-10-03T15:07:20+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2015-10-03T12:15:59+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=c0308c9319d40438db668e67fb944e08062148c7'/>
<id>c0308c9319d40438db668e67fb944e08062148c7</id>
<content type='text'>
Its absence was breaking the icon build on Ubuntu 14.04, because you
ask convert to map an image into a specific 16-colour palette, and it
does so and _then_ nonconsensually maps those colours in turn through
a colourspace transformation you didn't ask for, causing icon.pl to
fail an assertion when it finds an RGB value not in the palette.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Its absence was breaking the icon build on Ubuntu 14.04, because you
ask convert to map an image into a specific 16-colour palette, and it
does so and _then_ nonconsensually maps those colours in turn through
a colourspace transformation you didn't ask for, causing icon.pl to
fail an assertion when it finds an RGB value not in the palette.
</pre>
</div>
</content>
</entry>
<entry>
<title>New puzzle from James Harvey: 'Tracks'.</title>
<updated>2015-02-08T16:23:32+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2015-02-08T16:23:32+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=362bf8d450b6de02f8175afe979e2bca36d48c67'/>
<id>362bf8d450b6de02f8175afe979e2bca36d48c67</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>New puzzle: 'Flood'.</title>
<updated>2015-01-12T19:51:19+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2015-01-12T19:51:19+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=201b32983b5cd1f904da3614ee9136cfeec59818'/>
<id>201b32983b5cd1f904da3614ee9136cfeec59818</id>
<content type='text'>
Based on a web game I saw a few years ago, and dashed off this weekend
after I thought of a way to write a good (though not quite optimal)
heuristic solver, here's a random little thing not quite in the same
line as the most usual kind of Puzzles fare: instead of making you
scratch your head to find any move to make at all, it's easy to find
solutions in principle, and the challenge comes from having to do so
within a move limit.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Based on a web game I saw a few years ago, and dashed off this weekend
after I thought of a way to write a good (though not quite optimal)
heuristic solver, here's a random little thing not quite in the same
line as the most usual kind of Puzzles fare: instead of making you
scratch your head to find any move to make at all, it's easy to find
solutions in principle, and the challenge comes from having to do so
within a move limit.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix the icon makefile in the wake of r9795.</title>
<updated>2013-03-31T22:06:07+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2013-03-31T22:06:07+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=76824e16925df7d4aceae5f382bf53ddc55b94a0'/>
<id>76824e16925df7d4aceae5f382bf53ddc55b94a0</id>
<content type='text'>
[originally from svn r9797]
[r9795 == 3fc5a644a72e747b1f88125b38b2f178a9bc7ed3]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[originally from svn r9797]
[r9795 == 3fc5a644a72e747b1f88125b38b2f178a9bc7ed3]
</pre>
</div>
</content>
</entry>
<entry>
<title>New puzzle! 'Unruly', contributed by Lennard Sprong, is an</title>
<updated>2012-10-07T10:18:33+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2012-10-07T10:18:33+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=fc9e6277bdd8b354b9febe56b0022441430c4465'/>
<id>fc9e6277bdd8b354b9febe56b0022441430c4465</id>
<content type='text'>
implementation of a puzzle usually called 'Tohu wa Vohu'.

[originally from svn r9680]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
implementation of a puzzle usually called 'Tohu wa Vohu'.

[originally from svn r9680]
</pre>
</div>
</content>
</entry>
<entry>
<title>New puzzle! Contributed by Steffen Bauer, an implementation of</title>
<updated>2012-09-08T10:48:05+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2012-09-08T10:48:05+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=67ddba7a15573643666f0f4128d43d0095b80da0'/>
<id>67ddba7a15573643666f0f4128d43d0095b80da0</id>
<content type='text'>
'Haunted Mirror Maze', a game involving placing ghosts, zombies and
vampires in a grid so that the right numbers of them are visible along
sight-lines reflected through multiple mirrors.

[originally from svn r9652]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
'Haunted Mirror Maze', a game involving placing ghosts, zombies and
vampires in a grid so that the right numbers of them are visible along
sight-lines reflected through multiple mirrors.

[originally from svn r9652]
</pre>
</div>
</content>
</entry>
<entry>
<title>New puzzle! Or rather, new-ish, because this one has been lying around</title>
<updated>2012-01-22T14:14:26+00:00</updated>
<author>
<name>Simon Tatham</name>
<email>anakin@pobox.com</email>
</author>
<published>2012-01-22T14:14:26+00:00</published>
<link rel='alternate' type='text/html' href='https://www.franklinwei.com/cgit/puzzles/commit/?id=b16eece9fc502afb9dfb0aca9fd7bfba2239d3e3'/>
<id>b16eece9fc502afb9dfb0aca9fd7bfba2239d3e3</id>
<content type='text'>
in the 'unfinished' directory for a while, and has now been finished
up thanks to James Harvey putting in some effort and galvanising me to
put in the rest. This is 'Pearl', an implementation of Nikoli's 'Masyu'.

The code in Loopy that generates a random loop along grid edges to use
as the puzzle solution has been abstracted out into loopgen.[ch] so
that Pearl can use it for its puzzle solutions too. I've also
introduced a new utility module called 'tdq' (for 'to-do queue').

[originally from svn r9379]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
in the 'unfinished' directory for a while, and has now been finished
up thanks to James Harvey putting in some effort and galvanising me to
put in the rest. This is 'Pearl', an implementation of Nikoli's 'Masyu'.

The code in Loopy that generates a random loop along grid edges to use
as the puzzle solution has been abstracted out into loopgen.[ch] so
that Pearl can use it for its puzzle solutions too. I've also
introduced a new utility module called 'tdq' (for 'to-do queue').

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