long last to move all the Windows-specific source files down into a
`windows' subdirectory. Only platform-specific files remain at the
top level. With any luck this will act as a hint to anyone still
contemplating sending us a Windows-centric patch...
[originally from svn r4792]
directives that allow me to move some of the PuTTY-specific Makefile
fragments into Recipe. Not complete yet, but ought to be enough for
me to at least _try_ using mkfiles.pl in another project.
[originally from svn r4136]
will validate an md5sums manifest and if all md5sums match will use
a version number provided in a file. This should allow me to produce
a Unix release source archive with the property that when unpacked
and built it will produce binaries advertising themselves as
`Release X.YZ', but as soon as the user starts fiddling with the
sources it will revert to `Unidentified build' (though of course the
user can still _explicitly_ ask for a release tag, and in fact this
will override the default if any default is specified).
[originally from svn r3818]
caused a small amount of extra inconvenience at the tops of .rc
files, but it's been positive overall since lcc has managed to point
out some pedantic errors (typically static/extern mismatches between
function prototypes and definitions) which everything else missed.
[originally from svn r3744]
files as well as an nmake makefile. Needed line-end tweakery in
order to be able to generate usable project files when run on Unix,
but other than that appears fine. Ooh!
[originally from svn r3721]
&findfile() now caches its results. At least one full order of
magnitude speedup when running on an SMB-mounted volume. Phew.
[originally from svn r3720]
time. This gives rise to a whole bunch of spare warnings, one or two
of which might have been actual bugs; now all resolved.
[originally from svn r3134]
on Unix. So now mkfiles.pl will look in .. as well as . when
searching for Recipe, so I can run `perl ../mkfiles.pl' and it will
Just Work.
[originally from svn r3016]
functions turn out to be available only to PowerPC applications, through
WindowsLib and ControlsLib respectively, so we weak-link against those in
the obvious way.
[originally from svn r2441]
assuming that duplicate #includes of the same file are idempotent. I mean,
it's not even true for the standard headers (think <assert.h>), and
certainly isn't true here.
[originally from svn r2400]
does UTF-8 copy and paste (falling back to normal strings if
necessary), it understands X font encodings and translates things
accordingly so that if you have a Unicode font you can ask for
virtually any single-byte encoding and get it (Mac-Roman pterm,
anyone?), and so on. There's work left to be done (wide fonts for
CJK spring to mind), but I reckon this is a pretty good start.
[originally from svn r2395]
needlessly complex because Rez's preprocessor doesn't do either ANSI or K&R
stringification, and the MPW Shell isn't much good as shells go.
Also make _all_ the Mac executables depend on reources, not just the
Classic 68K one.
[originally from svn r2389]
of compiled resource file, .rsrc, which is built from .r, and adds mechanisms
to the MPW makefile generator to handle this.
[originally from svn r2385]
- Remove an unused library from the CFM-68K link line.
- Set the fragment name in CFM builds to "PuTTY".
- Set the hasBundle and isShared bits on freshly-created applications.
[originally from svn r2383]
than the Classic 68K version. This requires installing more bits of the
Text Encoding Converter SDK, since Apple seem to have forgotten to put _any_
68k bits for it, either CFM or Classic, in Universal Interfaces.
Also don't bother linking against libraries we don't seem to need.
[originally from svn r2379]
if it's available. Linking against the static Unicode Converter library
costs us about 30k on Classic 68K, which I can live with.
Because the default fallback converter can generate multiple output
characters for a single input character, we provide our own fallback that
doesn't. It converts everything to '?' instead.
[originally from svn r2315]
* splitline gets support for changing the continuation character.
* deps returns a data structure for the output routine to format as
appropriate.
* There's a new program type, [M], for Macintosh.
* There's a new backend to output mac/Makefile.mpw.
[originally from svn r2272]
needs to be able to handle separate Recipe entries for the same
program with different types (plink [C] and plink [X] for example,
with different object lists).
[originally from svn r2159]
