aboutsummaryrefslogtreecommitdiff
path: root/Recipe (follow)
Commit message (Collapse)AuthorAge
* Migrate to a CMake-based build system.Simon Tatham2021-03-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix Makefile.nestedvm so that it works with make -j.Simon Tatham2018-06-01
| | | | | | | | Instead of repeatedly reusing the file name 'PuzzleEngine.class' in the main build directory, now each puzzle's NestedVM translation is left in a separate subdirectory so that they don't collide with each other. A bonus is that we don't have to rename the file back and forth between the rule that builds it and the one that consumes it.
* Bump the source and target versions used in javac.Simon Tatham2018-05-14
| | | | | | | | I've just upgraded my build machine to Ubuntu 18.04, which has come with a version of javac that complains about both -source 1.3 and -target 1.3. Both are surely pretty out of date anyway, so the path of least resistance is to just increase them to the earliest version that javac doesn't currently complain is deprecated.
* Use the new matching() for latin.c.Simon Tatham2018-04-22
| | | | | | | | | | The new client code is a lot smaller and nicer, because we can throw away the col[] and num[] permutations entirely. Of course, this also means that every puzzle that incorporated latin.c now has to link against matching.c instead of maxflow.c - but since I centralised that secondary dependency into Recipe a few commits ago, it's trivial to switch them all over at once.
* Implementation of the Hopcroft-Karp algorithm.Simon Tatham2018-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a dedicated algorithm for finding a maximal matching in a bipartite graph. Previously I've been solving that problem in this code base using maxflow.c, modelling the graph matching problem as a restricted case of the optimal network flow problem and then using a full-strength algorithm for the latter. That's overkill, and also algorithmically wasteful - the H-K algorithm is asymptotically better, because it can find multiple augmenting paths in each pass (hence getting the maximum benefit out of each expensive breadth-first search), as a consequence of not having to worry about lower- or higher-value augmenting paths in this restricted problem. So I expect this algorithm to be faster, at least in principle or in large cases, when it takes over the jobs currently being done by maxflow. But that's not the only benefit. Another is that the data representation is better suited to the problems actually being solved, which should simplify all the call sites; a third is that I've incorporated randomisation of the generated matching into the H-K module itself, which will further save effort at each call site because they will no longer have to worry about permuting the algorithm's input - they just have to pass it a random_state and it will take care of that internally. This commit only introduces the new matching.c and builds a test utility for it. I haven't yet migrated any clients of maxflow.
* Recipe: centralise dependencies for latin.c.Simon Tatham2018-04-22
| | | | | | | | | | | | | | It's silly to have every puzzle using latin.c separately specify in its .R file the list of additional modules that latin.c depends on, or for that matter to have them all have to separately know how to adjust that for the STANDALONE_SOLVER mode of latin.c. So I've centralised a new pair of definitions into the core Recipe file, called LATIN and LATIN_SOLVER, and now a client of latin.c need only ask for that to get all the necessary dependencies too. Also, while I'm here, I've moved the non-puzzle-specific 'latincheck' test program out of unequal.R into the central Recipe.
* Set up a clang-cl makefile.Simon Tatham2017-08-24
| | | | | | 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.
* Add the 'make test' target to Makefile.am too.Simon Tatham2015-05-18
| | | | Now I don't have to annoyingly switch over to the GTK makefile.
* Move the benchmarking logic out into a script.Simon Tatham2015-05-18
| | | | | | | | It's a pain having it in a rule in Makefile.gtk, which isn't even the recommended makefile these days - it can't be re-run conveniently, and there's no way to parametrise it. Now it can be run no matter which makefile you're using, and it lets you narrow down to a subset of games (though not presets). Other options could easily be added.
* Remove the MD5-based manifest file system.Simon Tatham2014-09-24
| | | | | | | | | | | | A long time ago, it seemed like a good idea to arrange that binaries of my puzzles would automatically cease to identify themselves as a particular upstream version number if any changes were made to the source code, so that if someone made a local tweak and distributed the result then I wouldn't get blamed for the results. Since then I've decided the whole idea is more trouble than it's worth, so I'm retiring it completely. [originally from svn r10264]
* Remove dependencies on Subversion.Simon Tatham2014-09-24
| | | | | | | | | | | | | | | | I'm going through all my projects and reworking them to avoid depending on the monotonic integer-valued source control revision identifier provided by Subversion, so I can migrate everything to git without my builds and versioning breaking. Puzzles's version number is now of the form YYYYMMDD.vvvvvv, where vvvvvv is some string of source control information (currently still the SVN-style "rNNNNN", but free to change in future). The date provides monotonicity between my official automated builds, and the second component is the one I'll be most interested in when people send bug reports. [originally from svn r10263]
* Make svn-based version identification still work in VPATH builds.Simon Tatham2013-07-02
| | | | [originally from svn r9891]
* Fix small bugs in the automake construction which were preventing theSimon Tatham2013-07-02
| | | | | | | revision number from being automatically baked into the automake-built binaries. [originally from svn r9890]
* Add a mechanism to the automake system to allow 'make install' to onlySimon Tatham2013-06-30
| | | | | | install the actual games, not the auxiliary binaries or nullgame. [originally from svn r9887]
* Support building via autoconf and automake. mkfiles.pl now outputs aSimon Tatham2013-06-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]
* Remove stray bashisms from the NestedVM makefile.Simon Tatham2013-06-19
| | | | [originally from svn r9872]
* Introduce some extra testing and benchmarking command-line options toSimon Tatham2013-04-11
| | | | | | | | | | | | | | | | the GTK front end, plus a 'make test' target in the GTK makefile which uses them to automatically generate 100 puzzles for each game at each preset configuration, test-run them back through the solver without their aux_info to ensure that can cope, and produce an HTML box plot of game generation times for each preset. As part of this work I've removed the TESTSOLVE mechanism from r9549, since the new --test-solve option does the same thing better (in that when something goes wrong it prints the random seed that caused the problem). [originally from svn r9825] [r9549 == 5a095b8a08fa9f087b93c86aea0fa027138b028d]
* New front end! To complement the webification of my puzzles via JavaSimon Tatham2013-03-30
| | | | | | | | 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]
* For the convenience of Linux package maintainers, add to Makefile.gtkSimon Tatham2012-08-17
| | | | | | | | | | | | | and Makefile.doc a command-line parameter 'BINPREFIX' which will be prepended to all the game binary names. E.g. 'make BINPREFIX=sgt-' and 'make BINPREFIX=sgt- install', and correspondingly 'make -f Makefile.doc BINPREFIX=sgt-'. Also included in this commit by mistake, changes to singles.c to add \n to the end of all its debug() statements. I meant to commit that separately. Oops. [originally from svn r9606]
* Add a section to mkfiles.pl to build a makefile that compiles the OS XSimon Tatham2012-05-06
| | | | | | | | | front end using GNUstep, yielding a Unix program built from the same code. Should make it easier to check OS X behaviour without having to move as far as a Mac :-) However, it doesn't compile as is, so I'll apply fixes to the code until it does. [originally from svn r9498]
* Make mkfiles.pl clean under 'perl -w'. Fixes one minor bug in theSimon Tatham2010-05-29
| | | | | | | | output (a comment from Recipe mistakenly got into the Unix makefile); more importantly, lets mkfiles.pl run in up-to-date Perls (where implicit split to @_ is now obsolete). [originally from svn r8957]
* Fix a build-breaking bug I introduced to the OS X makefile in r8931.Simon Tatham2010-04-26
| | | | | | | | | (Missed off the explicit -o from the compile lines constructing version.{i386,ppc}.o, causing both to be compiled as version.o and dependent build steps to fail.) [originally from svn r8933] [r8931 == 36cee4e2796c23da15d3276e88416ad1ce035c4a]
* Modification of a patch from Debian: eliminate the endless rebuildsSimon Tatham2010-04-25
| | | | | | | | | | of basically unchanged binaries due to the compulsory rebuild of version.o. version.o now depends normally on version2.def, which is constructed using much the same if statements that version.o used to use, except that it's not overwritten at all if its contents don't need to change. [originally from svn r8931]
* Patch from James H to enable a single monolithic binary to be builtSimon Tatham2009-01-06
| | | | | | | | alongside the individual puzzle binaries, on Windows only. (MacOS already has it, of course; Unix would require about as much work again.) [originally from svn r8396]
* Stand-alone command-line interface to the obfuscate_bitmap()Simon Tatham2008-11-29
| | | | | | | | | function. Useful in conjunction with the new --save option to generate lots of games, extract the aux strings from the game generator, and de-obfuscate them in order to measure statistical properties of their solutions. [originally from svn r8352]
* Oops, left this out of r8178: having defined COMBINED everywhere inSimon Tatham2008-09-13
| | | | | | | the puzzles, we can now remove it from the OS X makefile section. [originally from svn r8179] [r8178 == 43eafe1fdf356c0c1c88936ffa79c83291973b5d]
* Michael Schierl's patch to compile the puzzles as Java applets usingSimon Tatham2008-06-10
| | | | | | NestedVM. Wow! [originally from svn r8064]
* Update the OS X Puzzles makefile so that it builds on Leopard andSimon Tatham2008-03-11
| | | | | | | | | | | | | | | | | | | | | | | generates PPC/Intel dual-architecture binaries. This turns out not to be too painful: you compile and link your programs using `gcc -arch ppc' or `gcc -arch i386', then you use a command of the form `lipo -create ppc-binary i386-binary -output binary' to construct a universal binary. It works equally well on command-line standalone executable files and the executables within application directories. Also added the -mmacosx-version-min option, since otherwise the OS X build tools appear to default to building binaries which will crash (without anything resembling a comprehensible error message) on any earlier release. The handling of version.o in this checkin is somewhat grotty. I'd prefer a method more cleverly intertwingled with mkfiles.pl so I didn't have to maintain the OS X architecture list in both mkfiles.pl and Recipe. (Not that I anticipate Apple switching architectures again in the immediate future, but it's the principle of the thing.) [originally from svn r7916]
* Dariusz Olszewski's changes to support compiling for PocketPC. ThisSimon Tatham2007-02-26
| | | | | | | | | | | | is mostly done with ifdefs in windows.c; so mkfiles.pl generates a new makefile (Makefile.wce) and Recipe enables it, but it's hardly any different from Makefile.vc apart from a few definitions at the top of the files. Currently the PocketPC build is not enabled in the build script, but with any luck I'll be able to do so reasonably soon. [originally from svn r7337]
* Marcin Wojdyr points out that the use of `>&' to redirect bothSimon Tatham2007-01-16
| | | | | | | stdout and stderr is non-standard. Switch to a POSIX-blessed alternative. [originally from svn r7116]
* Actually introduce the ability to build the Windows icons into theSimon Tatham2006-12-27
| | | | | | | | | | | | | | | | | | | 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]
* I'm sick of repeatedly adding and removing local changes to RecipeSimon Tatham2006-08-05
| | | | | | | | | | | | | | | | | | | | | | when testing a new game, so here's a new architecture for the Recipe file. mkfiles.pl now supports several new features: - an `!include' directive, which accepts wildcards - += to append to an existing object group definition - the ability to divert output to an arbitrary file. So now each puzzle has a `.R' file containing a fragment of Recipe code describing that puzzle, and the central Recipe does `!include *.R' to construct the Makefiles. That way, I can keep as many experimental half-finished puzzles lying around my working directory as I like, and I won't have to keep reverting Recipe when I check in any other changes. As part of this change, list.c is no longer a version-controlled file; it's now constructed by mkfiles.pl, so that it too can take advantage of this mechanism. [originally from svn r6781]
* New puzzle from James H: `Bridges', another Nikoli job.Simon Tatham2005-10-21
| | | | [originally from svn r6409]
* New puzzle: `Tents'. Requires a potentially shared algorithms moduleSimon Tatham2005-10-13
| | | | | | | maxflow.c. Also in this checkin, fixes to the OS X and GTK back ends to get ALIGN_VNORMAL right. This is the first time I've used it! :-) [originally from svn r6390]
* Various patches from Ben H: a fix for an outdated comment, a coupleSimon Tatham2005-09-05
| | | | | | | of spurious ps_printf() arguments removed, and an error check in the `make install' target. [originally from svn r6275]
* James H has implemented a new `Tricky' difficulty level in Light Up:Simon Tatham2005-09-01
| | | | | | | | | | | | | | | | | | a non-recursive level above Easy, which therefore moves the recursive Hard mode further up still. Play-testing suggests that in fact Tricky is often _harder_ than the old Hard mode, since the latter had limited depth of recursion and would therefore spot complex deductions only if it happened to start a recursion on the right square; Tricky may be limited in the sophistication of its complex deductions, but it never misses one, so its puzzles tend to be hard all over. Also in this checkin, a new source file `nullfe.c', containing all the annoying stub functions required to make command-line solvers link successfully. James wrote this for (the new) lightupsolver, and I've used it to simplify the other stand-alone solvers. [originally from svn r6254]
* Debian requires -lm, where Red Hat didn't.Simon Tatham2005-08-31
| | | | [originally from svn r6247]
* Now that Map has some seriously complex deductions, it's about timeSimon Tatham2005-08-31
| | | | | | | | | | | | it had a command-line solver. In order to do this, I've had to expose the internal region numbering because the solver has to have some way to state which region it means; and in any case it's also useful to have human-visible region numbering so that two people can discuss a puzzle they're solving together. So pressing L during play now toggles the display of region numbers; and `mapsolver' uses those same numbers when showing its working and its solutions. [originally from svn r6244]
* New puzzle: `Inertia', originally written for Windows by BenSimon Tatham2005-08-27
| | | | | | | Olmstead and reimplemented with the help of his source code which he was kind enough to release into the public domain. [originally from svn r6222]
* New puzzle: `Loopy', an implementation of Nikoli's `Slither Link' orSimon Tatham2005-08-24
| | | | | | `Loop the Loop' puzzle. Contributed by Mike Pinna. [originally from svn r6211]
* Native Windows printing support, using the infrastructure I put inSimon Tatham2005-08-20
| | | | | | | | | | | | | | | | | | | | | place in r6190. I'm quite pleased that I didn't have to modify the printing infrastructure _at all_ to make this work; the only source change required outside windows.c was the addition of a trivial utility function midend_get_params(), and that was for the benefit of bulk puzzle generation rather than anything to do with actual printing. As far as I can tell, all printable puzzles now print almost indistinguishably from the way they print under Unix. If you look closely the font is slightly different, and the Windows standard hatching doesn't seem to be quite as nice as the kind I did by hand in ps.c (and, particularly annoyingly, hatched areas don't show up at all for me when I print to a file and use gv, though they come out fine on the printer itself); but it's all there, and it all works. [originally from svn r6193] [r6190 == af59dcf6858264103bbc621761feee3aed5aaf2a]
* Substantial infrastructure upheaval. I've separated the drawing APISimon Tatham2005-08-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as seen by the back ends from the one implemented by the front end, and shoved a piece of middleware (drawing.c) in between to permit interchange of multiple kinds of the latter. I've also added a number of functions to the drawing API to permit printing as well as on-screen drawing, and retired print.py in favour of integrated printing done by means of that API. The immediate visible change is that print.py is dead, and each puzzle now does its own printing: where you would previously have typed `print.py solo 2x3', you now type `solo --print 2x3' and it should work in much the same way. Advantages of the new mechanism available right now: - Map is now printable, because the new print function can make use of the output from the existing game ID decoder rather than me having to replicate all those fiddly algorithms in Python. - the new print functions can cope with non-initial game states, which means each puzzle supporting --print also supports --with-solutions. - there's also a --scale option permitting users to adjust the size of the printed puzzles. Advantages which will be available at some point: - the new API should permit me to implement native printing mechanisms on Windows and OS X. [originally from svn r6190]
* New puzzle: `Map'. Vaguely original, for a change.Simon Tatham2005-08-13
| | | | | | | | | | (This puzzle is theoretically printable, but I haven't added it in print.py since there's rather a lot of painful processing required to get from the game ID to the puzzle's visual appearance. It probably won't become printable unless I get round to implementing a more integrated printing architecture.) [originally from svn r6186]
* A bunch of new reasoning techniques in the Slant solver, leading toSimon Tatham2005-08-06
| | | | | | | a new Hard mode. Also added a command-line `slantsolver' which can grade puzzles and show working. [originally from svn r6167]
* New puzzle: `Light Up', by James H.Simon Tatham2005-08-04
| | | | | | | | | | Also in this checkin (committed by mistake - I meant to do it separately), a behind-the-scenes change to Slant to colour the two non-touching classes of diagonals in different colours. Both colours are set to black by default, but configuration by way of SLANT_COLOUR_* can distinguish them if you want. [originally from svn r6164]
* New puzzle: `Slant', picked from the Japanese-language section ofSimon Tatham2005-08-02
| | | | | | | | | | | nikoli.co.jp (which has quite a few puzzles that they don't seem to have bothered to translate into English). Minor structural change: the disjoint set forest code used in the Net solver has come in handy again, so I've moved it out into its own module dsf.c. [originally from svn r6155]
* Another game from James H: `Black Box'.Simon Tatham2005-07-17
| | | | [originally from svn r6100]
* New puzzle: `Untangle', cloned (with the addition of random gridSimon Tatham2005-07-16
| | | | | | | | | | | | | | | generation) from a simple but rather fun Flash game I saw this morning. Small infrastructure change for this puzzle: while most game backends find the midend's assumption that Solve moves are never animated to be a convenience absolving them of having to handle the special case themselves, this one actually needs Solve to be animated. Rather than break that convenience for the other puzzles, I've introduced a flag bit (which I've shoved in mouse_priorities for the moment, shamefully without changing its name). [originally from svn r6097]
* New puzzle: Dominosa.Simon Tatham2005-07-14
| | | | [originally from svn r6091]
* Enhancements to mkfiles.pl and Recipe to arrange for the auxiliarySimon Tatham2005-07-05
| | | | | | | | | | | command-line programs (solosolver, patternsolver, mineobfusc) to be built as part of the normal Makefiles. This means mkfiles.pl now has the capability to compile a source file more than once with different #defines. Also, fixes for those auxiliary programs and one fix in midend.c which the Borland compiler objected to while I was testing its makefile generation. [originally from svn r6066]
generated by cgit v1.1 at 2026-04-25 11:40:32 +0000