| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
To begin with, the toolchain no longer lets me build for x86-32 -
apparently MacOS is now 64-bit only.
Also, the linker now gives an error about a missing libgcc_s variant
for -mmacosx-version-min=10.4, and indeed 10.5. So I've bumped the
minimum supported OS version to 10.6.
That in turn required some changes in osx.m itself, because bumping
the min OS version caused some API deprecations to show up. Luckily I
turned out to have left myself a comment some time ago telling me what
I was going to need to do about one of them :-)
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
I've built a set of 32-bit binaries, a 32-bit zip file and a 32-bit
MSI, all delivered into a 'w32' output directory.
|
| |
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
revision number from being automatically baked into the automake-built
binaries.
[originally from svn r9890]
|
| |
|
|
|
|
| |
install the actual games, not the auxiliary binaries or nullgame.
[originally from svn r9887]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
means I have to withdraw support for OS X 10.3 and PPC.
[originally from svn r9494]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
prevent annoying Perl warnings when $thing is undefined.
[originally from svn r9446]
|
| |
|
|
|
|
| |
makefile. Makes it easy to recompile for things like profiling.
[originally from svn r9154]
|
| |
|
|
|
|
| |
warnings;' to make it simpler.
[originally from svn r8966]
|
| |
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
add an include directory to the Windows makefile so that source
files in subdirectories can find the main headers.
[originally from svn r8802]
|
| |
|
|
|
|
| |
makefile.
[originally from svn r8782]
|
| |
|
|
|
|
|
| |
add "-ansi -pedantic" to the main Unix makefile, and clean up a few
minor problems pointed out thereby.
[originally from svn r8175]
|
| |
|
|
|
|
| |
NestedVM. Wow!
[originally from svn r8064]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
`osx-info.plist.o' which had crept into most of the Makefiles.
[originally from svn r7099]
|
| |
|
|
| |
[originally from svn r7033]
|
| |
|
|
| |
[originally from svn r7023]
|
| |
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
| |
&splitline in which a line is `split' into a line ending in a
backslash followed by a completely blank line.
[originally from svn r6710]
|
| |
|
|
|
|
|
|
|
| |
$(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]
|
| |
|
|
| |
[originally from svn r5973]
|
| |
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
2 and fallback to GTK 1.2.
[originally from svn r5705]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
| |
appears to be the approved Apple fashion.
[originally from svn r5197]
|
| |
|
|
|
|
|
|
|
|
| |
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]
|
|
|
I'd prefer to be able to share a single instance with PuTTY.
[originally from svn r4466]
|
