| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
so that not every machine on which I want to run the full Puzzles
build will have to have a local NestedVM installation.
[originally from svn r9882]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
web pages for the Java applets. Previously, those have all been
maintained by hand in my website's svn area, which is a bit silly. Now
we have a file per puzzle in the 'html' subdirectory which contains
the puzzle's name, one or two attributes, and the instructions snippet
to go below the puzzle applet; and then there's a Perl script that
builds all the real web pages out of that by adding in the parts
common across all files: the header, footer, and middle fragment with
the <applet> tag and resizing bits and pieces.
One piece _not_ checked in here is the footer text specific to my
hosting at chiark, which I think does still belong in the www area. So
Buildscr doesn't actually build the web pages; it just delivers the
bits and pieces by which my nightly snapshot script will be able to
run the program that _does_ build them, passing that footer as an
extra argument.
[originally from svn r9780]
|
| |
|
|
|
|
| |
working Mac and hence can't build it any more.
[originally from svn r9442]
|
| |
|
|
|
|
|
|
|
|
|
| |
(more finished) puzzles in 'unfinished', as Java applets only. (The
rationale being: puzzles in 'unfinished' can be played locally by
people who go to the extra effort of downloading and building the
source, but to play them in Java is particularly inconvenient unless I
build the Java version myself. I just won't link it from the front
page.)
[originally from svn r9073]
|
| |
|
|
| |
[originally from svn r8634]
|
| |
|
|
|
|
|
| |
pointed out that Help > About in the Java applets on my website
currently reports "Unidentified build".
[originally from svn r8105]
|
| |
|
|
|
|
|
| |
build process. Also update the new-puzzle checklist to make sure I
set up and test the Java applet for any new game I add.
[originally from svn r8096]
|
| |
|
|
|
|
|
|
|
|
| |
it got rid of the bogus backgrounds on all the text; but on the
other hand it mysteriously caused all the images to become black and
white! Serves me right for testing with Bridges which was B&W to
start with. Instead, we'll just tell xvfb to use a 24-bit display
and let it sort out the visuals for itself; that seems to work better.
[originally from svn r7932]
|
| |
|
|
|
|
| |
to fix the weird blacked-out text in the xvfb-built screenshots.
[originally from svn r7931]
|
| |
|
|
|
|
| |
I should at least check in what I've got.
[originally from svn r7542]
|
| |
|
|
|
|
| |
.htaccess.
[originally from svn r7324]
|
| |
|
|
| |
[originally from svn r7319]
|
| |
|
|
| |
[originally from svn r7224]
|
| |
|
|
| |
[originally from svn r7217]
|
| |
|
|
| |
[originally from svn r7215]
|
| |
|
|
|
|
| |
the .htaccess build work better :-)
[originally from svn r7214]
|
|
|
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]
|
