zakarya/puzzles
1
0
Fork 0
mirror of git://git.tartarus.org/simon/puzzles.git synced 2025-04-22 08:25:45 -07:00
Code Issues Packages Projects Releases Wiki Activity

I'm sick of repeatedly adding and removing local changes to Recipe

Browse Source 
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]
This commit is contained in:
Simon Tatham
2006-08-05 17:20:29 +00:00
parent f05c25347d
commit cf880225ed
30 changed files with 512 additions and 195 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
devel.but
View File

@ -193,7 +193,9 @@ end module builds a different puzzle.
\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} which contains a complete list of those game structures.
\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.
On the latter type of platform, source files may assume that the
preprocessor symbol \c{COMBINED} has been defined. Thus, the usual
@ -2916,9 +2918,10 @@ base), then there will be two global variables defined:
\c extern const int gamecount;
\c{gamelist} will be an array of \c{gamecount} game structures,
declared in the source module \c{list.c}. The application should
search that array for the game it wants, probably by reaching into
each game structure and looking at its \c{name} field.
declared in the automatically constructed source module \c{list.c}.
The application should search that array for the game it wants,
probably by reaching into each game structure and looking at its
\c{name} field.
}