This is the third of a series of savefile-related changes.
This adds early-days experimental support for a completely optional
'sfctool' utility (savefile conversion tool), to be able to export
a savefile's contents into a more portable format. There are likely
to be bugs at this stage. In this initial first-attempt, the export
format is a very simple ascii output.
NetHack can be built entirely, without also building this tool.
NetHack has no dependencies on the tool.
Attempts were made to minimize duplication of existing NetHack code.
To achieve that, unfortunately, #ifdef SFCTOOL and #ifndef SFCTOOL
had to be sprinkled around through some of the existing NetHack
source code, so that it could be re-used for building the utility.
The process for building the sfctool typically recompiles the source
files with #define SFCTOOL and a distinct object file with SF- is
produced.
sfctool notes:
Universal ctags is used and required to produce the sfctool utility.
Some targets were added to the Unix and Windows Makefiles to
facilitate the build process.
make sfctool
That should build a copy in util.
Note: At present, the Unix Makefiles do not copy sfctool over to the
NetHack playground during 'make install' or 'make update'.
Until that gets resolved by someone, The tool will
have to be manually copied there by the builder/admin if
desired.
cp util/sfctool ~/nh/install/games/lib/nethackdir/sfctool
Also, a separate Visual Studio sfctool.sln solution was written and
placed in sys/windows/vs. That has has only very limited testing.
Usage:
i) To convert an existing savefile to an exportascii format
that co-resides with the savefile:
sfctool -c savefile
That *must* be executed on the same platform / architecture /
data model that produced the save file in the first place.
ii) To unconvert an existing exportascii format export file to a
historical format savefile that can then be used by NetHack:
sfctool -u savefile
That must be executed on the same target platform / architecture /
data model that was used to build the NetHack that will
utilize the save file that results.
A Windows example:
sfctool -c Fred.NetHack-saved-game
That should result in creation of Fred.NetHack-saved-game.exportascii
from existing savefile:
%USERPROFILE%\AppData\Local\NetHack\3.7\Fred.NetHack-saved-game
A Unix example:
sfctool -c 1000wizard
That should result in creation of 1000wizard.exportascii.gz
from existing savefile in the playground save directory:
1000wizard.gz
Current Mechanics:
1. Makefile recipe, or script uses universal ctags to produce
util/sf.tags.
2. util/sftags is built and executed to read util/sf.tags and
generate: include/sfproto.h and src/sfdata.c.
3. util/sfctool is built from the following:
generated file compiled with -DSFCTOOL:
src/sfdata.c -> sfdata.o
existing files compiled with -DSFCTOOL:
util/sfctool.c -> sfctool.o
util/sfexpasc.c -> sfexpasc.o
src/alloc.c -> sf-alloc.o
src/monst.c -> sf-monst.o
src/objects.c -> sf-objects.o
src/sfbase.c -> sfbase.o
src/sfstruct.c -> sfstruct.o
src/nhlua.c -> sf-nhlua.o
util/panic.c -> panic.o
src/date.c -> sf-date.o
src/decl.c -> sf-decl.o
src/artifact.c -> sf-artifact.o
src/dungeon.c -> sf-dungeon.o
src/end.c -> sf-end.o
src/engrave.c -> sf-engrave.o
src/cfgfiles.c -> sf-cfgfiles.o
src/files.c -> sf-files.o
src/light.c -> sf-light.o
src/mdlib.c -> sf-mdlib.o
src/mkmaze.c -> sf-mkmaze.o
src/mkroom.c -> sf-mkroom.o
src/o_init.c -> sf-o_init.o
src/region.c -> sf-region.o
src/restore.c -> sf-restore.o
src/rumors.c -> sf-rumors.o
src/sys.c -> sf-sys.o
src/timeout.c -> sf-timeout.o
src/track.c -> sf-track.o
src/version.c -> sf-version.o
src/worm.c -> sf-worm.o
src/strutil.c -> strutil.o
This is the second of a series of changes related to save/restore.
No EDITLEVEL bump has been included, because although the code
is changed extensively by this, the content of the savefiles have
not been changed.
Push the use of the structlevel bwrite() and mread() function use
out of the core and into sfstruct.c. This is groundwork for upcoming
changes.
In the core, replace the bwrite() and mread() calls with the
use of type-specific savefile output (Sfo) and savefile
input (Sfi) macros. The macros are defined in a new header file
savefile.h, which also contains the prototypes for the sfo_* and
sfi_* functions that the macros ultimately expand to. The functions
themselves are in src/sfbase.c.
On C99, each Sfo or Sfi macro expansion refers directly to the
corresponding type-specific sfo_* or sfi_* function.
If C23 or later is is use, the majority (all but 3 types) of the
macros refer to a single _Generic output routine sfo(nhfp, dt, tag),
and a single _Generic input routine sfi(nhfp, dt, tag), which handles
the dispatch of the type-specific underlying functions. This was
somewhat experimental, but turned out to be practical because the
compiler would gripe if the type for a variable was not included in
the _Generic when passed as an argument, so it could be fixed.
This alters the savefile verication process by having a common set
return values for the related functions such as uptodate(),
check_version(), etc. The new return values return more information
about savefile incompatibilities, beyond failure/sucess. The
additional information will be useful for an upcoming addition.
The expanded return values are:
SF_UPTODATE (0) everything matched and looks good
SF_OUTDATED (1) savefile is outdated
SF_CRITICAL_BYTE_COUNT_MISMATCH (2) critical size count mismatch
SF_DM_IL32LLP64_ON_ILP32LL64 (3) Windows x64 savefile on x86
SF_DM_I32LP64_ON_ILP32LL64 (4) Unix 64 savefile on x86
SF_DM_ILP32LL64_ON_I32LP64 (5) x86 savefile on Unix 64
SF_DM_ILP32LL64_ON_IL32LLP64 (6) x86 savefile on Windows x64
SF_DM_I32LP64_ON_IL32LLP64 (7) Unix 64 savefile on Windows x64
SF_DM_IL32LLP64_ON_I32LP64 (8) Windows x64 savefile on Unix 64
SF_DM_MISMATCH (9) some other mismatch
The callers in the core have been adjusted to deal with the expanded
return values.
Other miscellaneous inclusions:
- go.oracle_loc -> svo.oracle_loc.
- add a bit (1UL << 30) to called SFCTOOL_BIT as groundwork
for changes to follow.
We've had reports of a couple of issues building against musl libc.
Issues reported:
- build procedures utilize cat for Guidebook-creation, and cat
is deprecated in distros that use musl libc.
- some of the CRASHREPORT code is using library functions that
are not available in the musl libc environment. The reported
functions were backtrace() and backtrace_symbols(), which use
header file /usr/include/execinfo.h.
So we'll try to accommodate this. Since we don't have a means of
autodetecting the musl libc situation during the build (as of yet), the
builder will have to specify 'make musl=1' on the make command line.
Specifying 'musl=1' on the make command line will:
1. ensure that NOCRASHREPORT gets defined in the C preprocessor.
2. set COLCMD to be '../util/stripbs' instead of 'col -bx'.
Closes#1393
In case someone switches from NetHack-3.6 to NetHack-3.7 and does
'make spotless' after the switch instead of before, get rid of out
of date lev_comp and dgn_comp.
new .h files: hacklib.h selvar.h stairs.h
new .c files: calendar.c, getpos.c, report.c, selvar.c, stairs.c,
strutil.c, wizcmds.c
cleanup of hacklib.c and mdlib.c
hacklib contains functions that do not have to link with the core
relocate wiz commands from cmd.c to wizcmds.c
relocate CRASHREPORT stuff to report.c
relocate getpos stuff from do_name.c to getpos.c
remove temporary struct definition from extern.h
cross-compile PRE-section split into cross-pre1.370 and cross-pre2.370
Windows sys/windows/Makefile.nmake and sys/windows/Makefile.mingw32 and
visual studio project file updates
Unix sys/unix/Makefile.src, sys/unix/Makefile.utl
populate selvar.c and selvar.h
build on MS-DOS (not cross-compile) Makefile updates
for sys/msdos/Makefile.GCC (untested)
vms updates for above (untested)
The dependencies in util/Makefile duplicate those in src/Makefile for
objects.o and monst.o but the latter got changed last year and the
change wasn't replicated.
CSTD can be manually set near the top of src/Makefile, util/Makefile
or by including c99=1 or C99=1 on the build make command line if
using the linux.370 or macOS.370 hints files.
Have 'make clean' and 'make spotless' in 3.7 cleanup include/tile.h
from 3.6. Otherwise use of 'cc -I../include -I../win/share' in
util/Makefile will get 3.6's include/tile.h instead of 3.7's
win/share/tile.h; use of FDECL() causes the old header to break when
used in various tiles utilities.
include/.gitignore should continue to ignore old files in case
someone checks out an older version, builds, then checks out the
current version without running 'make spotless' first.
sys/unix/Makefile.utl: tiletxt.o depends on tilemap.c in addition
to tiletxt.c.
observed: parallel build attempts of makedefs that trampled over
one another.
attempted workaround: Add a dependency as per Pat R's suggestion.
observed: Concurrent header file movement collisions were sometimes
causing file busy errors and build failures.
workaround: Eliminate tile.h header file movement from the
Makefile build so that the collisions won't occur with that
particular file. Leave the header file tile.h in win/share as it
is in the distribution and just adjust the include path in the
rule for the specific files that use it.
observed: tiletxt.c created on-the-fly from Makefile echo statements
sometimes resulted in garbled and duplicate content in it when
parallel makes were involved, and that caused a build failure.
workaround: Instead of creating a tiletxt.c on-the-fly via echo
statements in the Makefile, simplify things and use that
same #include "tilemap.c" approach but make it an actual file
in the distribution. That makes it available for other platforms
too.
Avoids any need for MONITOR_HEAP hackery. Link src/alloc.o and
util/panic.o into util/makedefs.
When replacing the realloc() call in fgetline(), I noticed that
fgetline() would miss the last line of an input file if it lacked a
terminating newline. This was hard to test because OSX seems to be
supplying one when it is missing (VMS would do that too). I had to
modify epitaph (my test bed) to take off the final character, run
'makedefs -s' under debugger control and strip away final newline
that stdio added back, build new nhdat and move it into place, then
run nethack and execute #wizrumorcheck all multiple times before
the fix and once more after it. Much effort for little gain...
Plus some of the recent reformatting: indent labels one space,
replace tabs with spaces, shorten or split wide lines.
Be able to run 'make Guidebook{|.txt|.ps}' in the doc subdirectory
without requring a full install first.
makedefs is no longer one of the first things built when building
nethack, and even if it was, nobody should have to rebuild all of
nethack after 'make spotless' when they just want to create one
or more of the formatted Guidebooks. The 'roff versions (.ps and
also .txt) use makedefs as a filter by default, so wouldn't build
if it wasn't there.
Have Makefile.doc build makedefs when needed.
Clean up some dependencies in Makefile.utl.
Add a couple of comments to Makefile.src.
The walls for the mines, gehennom, knox, and sokoban had been
changed at the "tile"-level, with no awareness of the core game,
or non-tile interfaces.
- Expand the glyphs to include a set of walls for the main level
as well as each of those mentioned above.
Altars had been adjusted at the map_glyphinfo() level to substitute
some color variations on-the-fly for unaligned, chaotic, neutral,
lawful altars, and shrines. The tile interface had no awareness of
the feature.
- Expand the glyphs to include each of the altar variations that
had been implemented in the display code for tty-only. This required
the addition of four placeholder tiles in other.txt. Someone with
artistic skill will hopefully alter the additional tiles to better
reflect their intended purpose.
Explosions had unique tiles in the tile window port, and the display
code for tty tinkered with the colors, but the game had very little
awareness of the different types of explosions.
- Expand the glyphs to include each of the explosion types: dark,
noxious, muddy, wet, magical, fiery and frosty.
Pile-markers to represent a pile had been introduced at the
display-level, without little to no awareness by the core game.
- Expand the glyphs to include piletops, including objects,
bodys, and statues.
Recently male and female variations of tiles and monsters had been
had been introduced, but the mechanics had been mostly done at the
display-level through a marker flag. The window port interface then
had to increment the tile mapped to the glyph to get the female version
of the tile.
- Expand the glyphs to include the male and female versions of the
monsters, and their corresponding pet versions, ridden, detected
versions and statues of them.
Direct references to GLYPH_BODY_OFF and GLYPH_STATUE_OFF
in object_from_map() in pager.c were getting incomplete results.
- Add macros glyph_to_body_corpsenm(glyph) and
glyph_to_statue_corpsenm(glyph) macros for obtaining the corpsenm
value after passing the glyph_is_body() or glyph_is_statue() test.
Other relevant notes:
- The tile ordering in the win/share/*.txt tile files has been altered,
other.txt in particular.
- tilemap.c has had a lot of alterations to accommodate the expanded
glyphs. Output that is useful for troubleshooting will end up in
tilemappings.lst if OBTAIN_TILEMAP is defined during build.
It lists all of the glyphs and which tile it gets mapped to, and also
lists each tile and some of the references to it by various glyphs.
- An array glyphmap[MAXGLYPH] is now used. It has an entry for each
glyph, ordered by glyph, and once reset_glyphs(glyph) has been run, it
contains the mapped symindex, default color, glyphflags, and tile
index.
If USE_TILES is defined during build, the tile.c produced from the
tilemap utility populates the tileidx field of each array element with
a glyph-to-tile mapping for the glyph. Later on, when reset_glyphmap()
is run, the other fields of each element will get populated.
- The glyph-to-tile mapping is an added field available to a window
port via the glyphinfo struct passed in the documented interface. The
old glyph2tile[] array is gone. The various active window ports that
had been using glyph2tile[] have been updated to use the new interface
mechanism. Disclaimer: There may be some bug fixing or tidying
required in the window port code.
- reset_glyphmap() is called after config file options parsing
has finished, because some config file settings can impact the results
produced by reset_glyphmap().
- Everything that passes the glyph_is_cmap(glyph) test must
return a valid cmap value from glyph_to_cmap(glyph).
- An 'extern glyph_info glyphmap[MAX_GLYPH];' is inserted into the
top of only the files which need awareness of it, not inserted into
display.h. Presently, the only files that actually need to directly
reference the glyphmap[] array are display.c, o_init.c (for shuffling
the tiles), and the generated tile.c (if USE_TILES is defined).
- Added an MG_MALE glyphflag to complement the MG_FEMALE glyphflag.
- Provide an array for wall colorizations. reset_glyphmap() will draw
the colors from this array: int array wallcolors[sokoban_walls + 1];
The indices of the wallcolors array are main_walls (0), mines_walls
(1), gehennom_walls (2), knox_walls (3), and sokoban_walls (4).
In future, a config file option for adjusting the wall colors and/or
an 'O' option menu to do the same could be added. Right now, the
initializaton of the wallcolors[] array entries in display.c leaves the
walls at CLR_GRAY, matching the defsym color.
- Most of the display-level kludges for some of the on-the-fly
interface features have been removed from map_glyphinfo() as they
aren't needed any longer. These glyph expansions adhere more closely to
the original glyph mechanics of the game.
- Because the glyphs are re-ordered and expanded, an update to
editlevel will be required upon merge of these changes.
This evolves and hopefully eases the game-build requirements by
removing game-compile dependencies on any header files generated
by the makedefs utility, including:
date.h dependency and its inclusion is removed and comparable functionality
is produced at runtime via new file src/date.c.
pm.h dependency and its inclusion is removed and comparable functionality is
produced by moving the monster definitions from monst.c into new header
file called monsters.h and altering them slightly. The former pm.h header
file #define PM_ values are now replaced with appropriate emitted enum
entries during the compiler preprocessing.
onames.h dependency and its inclusion is removed and comparable functionality
is produced by moving the object definitions from objects.c into new header
file called objects.h and altering them slightly. The former onames.h header
file #define values are now replaced with appropriate emitted enum entries
during the compiler preprocessing.
artilist.h has been slightly altered, and the former onames.h artifact-related
header file #define ART_ values are now replaced with appropriate emitted enum
entries during the compiler preprocessing.
makedefs can still produce date.h (makedefs -v), pm.h (makedefs -p), and
onames.h (makedefs -o) for reference purposes. They won't be used during
the compiler.
The other uses for makedefs remain. They are used to prepare external
file content that the game utilizes, not prerequisite code for the
compile:
makedefs -d (database)
makedefs -r (rumors)
makedefs -h (oracles)
makedefs -s (epitaphs, engravings, bogusmons)
date.c
Pull the code for date/time stamping from mdlib.c into date.c.
Set date.o to be dependent on source files, header files, and .o files
so that date.o is rebuilt from date.c when any of those changes, thus
ensuring an accurate date/time stamp. It also includes git sha
functionality formerly done by makedefs writing #define directives
into include/date.h. For unix it passes the git info on
the compile line for date.c (via sys/unix/hints/linux.2020, macOS.2020)
nethack --dumpenums (optional, but on by default)
Allow developer to obtain some internal enum values from NetHack
without having to resort to an external utility such as
makedefs.
Uncomment #define NODUMPENUMS in config.h to disable this.
The updates to sys/windows/Makefile.gcc have not been tested yet.
There were multiple symbol-related lists that had to be kept
in sync in various places.
Consolidate some of that into a single new file
defsym.h
with a set of morphing macros that can be custom-called from
the various places that use the sym info without maintaining
multiple occurrences. Most maintenance can be done there.
Rename monsym.h to sym.h since it looks after some
symbols not related to monsters now too.
The defsym.h header file is included in multiple places to
produce different code depending on its use and the controlling
macro definitions in place prior to including it.
Its purpose is to have a definitive source for
pchar, objclass and mon symbol maintenance.
The controlling macros used to morph the resulting code are
used in these places:
- in include/sym.h for enums of some S_ symbol values
(define PCHAR_ENUM, MONSYMS_ENUM prior to #include defsym.h)
- in include/objclass.h for enums of some S_ symbol values
(define OBJCLASS_ENUM prior to #include defsym.h)
- in src/symbols.c for parsing S_ entries in config files
(define PCHAR_PARSE, MONSYMS_PARSE, OBJCLASS_PARSE prior
to #include defsym.h)
- in src/drawing.c for initializing some data structures/arrays
(define PCHAR_DRAWING, MONSYMS_DRAWING, OBJCLASS_DRAWING prior
to #include defsym.h)
- in win/share/tilemap.c for processing a tile file
(define PCHAR_TILES prior to #include defsym.h).
Remove all references to the unused vision tables in the main source
and unix build. Leave makedefs able to generate the vision tables.
makdefs will be cleaned up in a different commit, once all ports
are clear of dependencies.
Replace use of $(LINK) with $(CLINK) or $(CXXLINK) as warranted.
When the Qt interface is enabled, the utility programs were all
(except dlb) being linked with C++ support. That didn't cause
any problems, just looked wrong. Link them as C instead of C++.
Two actually do need C++ support (and still have it) but both
are dead: 'tile2beos' because the source file doesn't exist (not
even in 'outdated'), 'tileedit' because it won't build with Qt5.
I didn't bother with QUIETCC support for them.
There were still a couple of references to dgn_comp (for the lint
target; just in the name of a macro, not its value); remove those.
Expand the use of the sys/unix Makefiles to be used for both normal
local builds and installs, as well as cross-compiles for other
platforms/targets.
Up until now, the primary unix Makefiles have treated util/host-side
component compiles, links and target object files just the same as
the game component compiles, links, and target object files.
Unfortunately, that meant that cross-compile effort typically had
to re-invent Makefiles specific to the cross-compile, creating a
maintenance burden and deviation from the typical local unix build
and providing a daunting obstacle to those that want to establish
build for a target environment/platform.
This change distinguishes between util/host-side component builds,
links, and component builds and targets object files destined for
the game (and other target platforms) in the Makefiles.
In theory, this will ease the effort for people that want to try to
resurrect NetHack perhaps on an old platform where it is no longer
viable to build NetHack-3.7 on the platform itself using old, outdated
compile tools, possibly with an old, outdated C dialect.
Some details:
- Game-related targets in the Makefiles (as opposed to util/host-side
targets that will be executed on the host), which could be destined
for another platform in a cross-compile scenario are prefixed with
$(TARGETPFX) so that they are distinguished.
The default scenario where no cross-compiler is involved, is to
define TARGETPFX to nothing, and therefore meant to have no effect.
- Game-related compile and link commands in the Makefiles and their
associated command line flags are distinguished from util/host-side
compile and link commands in the Makefiles by using $(TARGET_CC),
$(TARGET_CFLAGS), $(TARGET_LINK), $(TARGET_LFLAGS), $(TARGET_CXX),
$(TARGET_CXXFLAGS), $(TARGET_LIBS).
Those are used in the Makefile in place of $(CC), $(CFLAGS), $(LINK),
$(LFLAGS), $(CXX), $(CXXFLAGS), $(LIBS).
The default scenario where no cross-compiler is involved, defines
the TARGET_ version of those Makefile variables to match their
typical non-TARGET_ ounterparts.
- The dependency lists in the Makefiles includes the $(TARGETPFX)
prefix for stuff that would potentially be produced from a
cross-compile build.
- It adds pregame targets and $(PREGAME) variable, so that hints files
can add some additional stuff if required for a cross-compile
scenario.
The default scenario where no cross-compiler is involved doesn't
do anything for $(PREGAME).
- It adds $(BUILDMORE) target and variable, so that hints files
can add some additional things to be built for a cross-compile
scenario.
- It adds a "package" target and $(PACKAGE) variable, so that hints files
can add steps for the target platform in a cross-compile
scenario.
The "install" target assumes local build and placement and
isn't really applicable to a cross-compile scenario where the results
really just need to be bundled up for transport to the target platform.
- Also, this adds a pair of include files that can be updated with some
cross-compile recipes as they evolve. They are named "cross-pre.2020"
(for stuff to be included in the PRE section) and "cross-post.2020"
for stuff to be included in the POST section via sys/unix/setup.sh.
Those are included in sys/unix/hints/linux.2020 and
sys/unix/hints/macOS.2020 hints files.
Build feedback filtered by a script which filters out -Dthis -Wthat:
gcc -g -I../include -I../lib/lua-/src -c ../win/share/tilemap.c
The second -I is obsolete or else its bogus value would have caused
build failure. When removing it, I noticed that there was still quite
a bit of obsolete yacc and lex stuff in there. Remove that too.
Unix Makefile.utl wasn't aware of the dependency of makedefs.o on
src/mdlib.c so didn't rebuild makedefs when it should have.
Eliminate several warnings:
mdlib.c - #if inside the arguments to macro Sprintf();
nhlua.c - nhl_error() ends with a call to lua_error() which doesn't
return, but neither of them were declared that way;
nhlsel.c - because of the previous, the 'else error' case of
l_selection_ellipse() led to complaints about uninitialized
variables;
sp_lev.c - missing 'const'.
I did minimal testing which went ok, but revisiting a couple of levels
gave me un-freed memory allocated by restore.c line 1337. (I haven't
looked at that at all.)
Game is playable, and should compile on linux and Windows.
Assumes you have a lua 5.3 library available.
Removes level compiler and associated files.
Replaces special level des-files with lua scripts.
Exposes some NetHack internals to lua:
- des-table with commands to create special levels
- nh-table with NetHack core commands
- nhc-table with some constants
- u-table with some player-specific data (u-struct)
- selection userdata
Adds some rudimentary tests.
Adds new extended command #wizloadlua to run a specific script,
and #wizloaddes to run a specific level-creation script.
nhlib.lua is loaded for every lua script.
Download and untar lua:
mkdir lib
cd lib
curl -R -O http://www.lua.org/ftp/lua-5.3.5.tar.gz
tar zxf lua-5.3.5.tar.gz
Then make nethack normally.
Make some progress on a couple of next minor release checklist
items, hopefully without introducing too many new bugs. This
is just the initial commit, and work continues.
Checklist items:
Savefiles compatible between Windows versions, whether 64-bit
or 32-bit in little-endian field format.
Selection of file formats:
historical (structlevel saves),
lendian (little-endian, fieldlevel saves),
and just for proof-of-concept, ascii fieldlevel saves
(the ascii is huge! 10x bigger than little-endian).
For the fieldlevel save, all complex data structures recursively
get broken down until until it is one of the simple types that
can't be broken down any further, and that gets when it gets
written to the output file.
New files needed for this build:
hand-coded:
include/sfprocs.h
src/sfbase.c - really a dispatcher to one of the
output/input format routines.
src/sflendian.c - little-endian output writer/reader.
src/sfascii.c - ascii text output writer/reader.
auto-coded (generated):
include/sfproto.h
src/sfdata.c
This is just one approach. I'm sure there are countless others
and they have different pros and cons.
For producing the auto-coded files a utility called
universal-ctags, that is actively maintained and evolving,
was used to do all the heavy-lifting of parsing the
NetHack C sources to tabulate the data fields, and store
them in an intermediate file called util/nethack.tags
(not required for building NetHack if you already have a
generated include/sfproto.h and src/sfdata.c)
util/readtags (also not required for building NetHack
itself) will decipher the nethack.tags file and produce
the functions that can deal with the NetHack struct data
fields.
You can obtain the source for universal-ctags by cloning it
from here:
https://github.com/universal-ctags/ctags.git
The combination universal-ctags + util/readtags has been
tried and tested under both Windows and Linux, so it is
not tied to a particular platform.
Note: util/readtags will work only with universal-ctags
output, so other ctags are unlikely to work as-is.
Universal-ctags can be build from source very easily
under Linux, or under Windows using visual studio.
When dgn_comp.l and lev_comp.l are processed by older versions of
flex, 'gcc -Wunused' complains when compiling dgn_lex.c and lev_lex.c
because flex creates 'static void yyunput()' and nethack doesn't use
it. Newer versions honor macro YY_NO_UNPUT to hide the offending
code, but that doesn't help with older versions (like the one
masquerading as 'lex' on OSX). Adding a dummy usage would probably
cause problems with other lexers, so change it from static to
'void yyunput()' as a 'sed' fixup in util/Makefile after flex has
finished. That will be a no-op when yyunput doesn't exist or isn't
static.
In addition to the sys/unix/Makefile.utl change, this checks in new
sys/share/{dgn,lev}_lex.c with the fixup in place.
