OS X is beginning to show a warning when a 32-bit application is
opened, so it's high time that this gets enabled. Fix a clang warning
exposed by this build.
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.
This is a combination of PuTTY r10142 and the relevant pieces of
r10141: we now enable the 'subdir-objects' mode in Makefile.am, and
stop using $(subdir) in source file paths.
(As a consequence of the latter the automake machinery now cannot live
anywhere but at the top level of the source tree, but since that's
where it was already, this is less of an upheaval here than it was for
PuTTY!)
[originally from svn r10146]
[r10141 == a947c49bec36957cb5d38e1dc2e22dc0e3465849 in putty repository]
[r10142 == 0da225829234744b1141aea3a7c54ad7d74679a7 in putty repository]
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]
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]
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]
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]
reported on the same day that this is now necessary since up-to-date
GNU tools won't consider it sufficient to have libm be a dependency of
other explicitly referenced libraries if you're directly referring to
the contents of libm yourself.
[originally from svn r9448]
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]
$mw (it should only ever have been used in the Cygwin makefile), and
move the libraries to the end of the link line in the Unix makefile
for better portability.
[originally from svn r8853]
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]
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]
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]
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]
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]
$(XFLAGS) _after_ $(CFLAGS) on the compiler command lines, meaning
that you can provide options in XFLAGS on the makefile which will
override the ones in CFLAGS. For example, `make XFLAGS=-O0' to make
debugging easier.
[originally from svn r6123]
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]
ends. Versioning will be done solely by Subversion revision number,
since development on these puzzles is very incremental and gradual
and there don't tend to be obvious points to place numbered
releases.
[originally from svn r5781]
builds better:
- the GTK makefile now defines $(GTK_CONFIG) which you can
override, so you can build for GTK 2 with no makefile-editing
simply by running `make GTK_CONFIG="pkg_config gtk+-2.0"'
- we use Pango to find appropriate fonts, which means the text in
the puzzles actually (gasp!) adapts its size to the
circumstances. Unfortunately, I've been unable to do this
portably without depending on _either_ a Pango function that
isn't present in older versions _or_ the underlying window system
being X11; I'd appreciate someone doing better.
[originally from svn r5693]
platform-dependent code in puzzles.h (ick), which in turn depended
on the magic symbol MAC_OS_X being defined by mkfiles.pl itself
(yuck). Suddenly realised I can do much better simply by putting it
in an OS X makefile extras section in Recipe, and removing both
previous hacks. Much nicer.
[originally from svn r5191]
of the manual using Halibut (with one additional magic tag in the
<HEAD> section), stuck it in the right part of the application
bundle, referenced it in Info.plist, and added a Help menu.
Everything else was automatic. Not bad!
[originally from svn r5190]
Mac OS X application bundle, and provided an icon for Puzzles.
Also renamed the OS X source file from macosx.m to osx.m, so that it
can sit beside other things such as osx-info.plist and not cause
enormously long filenames.
[originally from svn r5179]
puzzles are compiled together into a single monolithic application
which allows you to select each one from one of its menus.
[originally from svn r5173]
