I tried wishing for "splashes of venom" but was told that no such
thing exists even though "splashs of venom" and "2 splash of venom"
both work to produce "2 splashes of venom". After the spurious
failure, retrying with EDIT_GETLIN enabled showed that "splashes"
had been singularized to "splashe" so fix that.
"2 splashes of venom" IDed to "2 uncursed blinding venoms" because
the base name omits "splash of" prefix. And due to that, explicitly
wishing for "splash of {acid,blinding} venom" didn't work either.
Change the names to include the prefix, and add a hack to makedefs
to keep generating the old macro names without the prefix. (Wishing
for "{acid,blinding} venom" still works due to post-3.6.6 changes
to " of " matching.)
Fixes#369.
Fixes#370.
The default entries inserted by makedefs -s (starting in 3.6.6,
to guard against having an empty data file which led to divide by
zero crash when nethack picked a random entry) lacked a terminating
newline so the first entry from the file (for the usual case when
that data file wasn't empty) got implicitly concatenated to it.
If the first entry got chosen during play, the initial portion
corresponding to the default entry was decrypted properly but the
concatenated portion corresponding to file's first line didn't.
So gibberish was appended to default engraving or epitaph or bogus
monster; also, the input file's first line would never appear.
The newline fix in makedefs is different from pull request #370
but accomplishes the same thing.
The bulk of the patch is an enhancement to #wizrumorcheck to show
first (default inserted by makedefs), second (first in input file)
and last engravings, epitaphs, and bogusmons in addition to rumors.
The command name has become a little misleading but the limited
functionality doesn't call for separate commands.
Have 'makedefs -m' output default mons[].difficulty values in the
stub 'monstr.c' that still gets generated for that option. It
would be better to allow specifying which monsters are of interest
but I didn't want to get bogged down by interface issues.
I needed it for mons[PM_ELF].difficulty after changing that monster's
level, so it still has a purpose. Code is from 3.4.3, reformatted
manually.
Eliminate a couple of warnings about unused static routines.
That led to a couple of other things.
I hope I got host vs target right in the mdlib.c '#if's.
Some support of new code #defines to faciliate cross-compiling:
OPTIONS_AT_RUNTIME If this is defined, code to support obtaining
the compile time options and features is
included. If you define this, you'll also have
to compile sys/mdlib.c and link the resulting
object file into your game binary/executable.
CROSSCOMPILE Flags that this is a cross-compiled NetHack build,
where there are two stages:
1. makedefs and some other utilities are compiled
on the host platform and executed there to generate
some output files and header files needed by the
game.
2. the NetHack game files are compiled by a
cross-compiler to generate binary/executables for
a different platform than the one the build is
being run on. The executables produced for the
target platform may not be able to execute on the
build platform, except perhaps via a software
emulator.
The 2-stage process (1. host, 2.target) can be done
on the same platform to test the cross-compile
process. In that case, the host and target platforms
would be the same.
CROSSCOMPILE_HOST Separates/identifies code paths that should only be
be included in the compile on the host side, for
utilities that will be run on the host as part of
stage 1 to produce output files needed to build the
game. Examples are the code for makedefs, tile
conversion utilities, uudecode, dlb, etc.
CROSSCOMPILE_TARGET Separates/identifies code paths that should be
included on the build for the target platform
during stage 2, the cross-compiler stage. That
includes most of the pieces of the game itself
but the code is only flagged as such if it must
not execute on the host.
If you don't define any of those, things should build as before.
One follow-on change that is likely required is setting the new dependency
makedefs has on src/mdlib.c in Makefiles etc.
More information about the changes:
makedefs
- splinter off some of makedefs functionality into a separate file
called src/mdlib.c.
- src/mdlib.c, while included during the compile of makedefs.c
for producing the makedefs utility, can also be compiled
as a stand-alone object file for inclusion in the link step
of your NetHack game build. The src/mdlib.c code can then
deliver the same functionality that it provided to makedefs
right to your NetHack game code at run-time.
For example, do_runtime_info() will provide the caller with
the features and options that were built into the game.
Previously, that information was produced at build time on the
host and stored in a dat file. Under a cross-compile situation,
those values are highly suspect and might not even reflect the
correct options and setting for the cross-compiled target
platform's binary/executable. The compile of those values and
the functionality to obtain them needs to move to the target
cross-compiler stage of the build (stage 2).
- date information on the target-side binary is produced from
the cross-compiler preprocessor pre-defined macros __DATE__
and __TIME__, as they reflect the actual compile time of the
cross-compiled target and not host-side execution of a utility
to produce them. The cross-compiler itself, through those
pre-defined preprocessor macros, provides them to the target
platform binary/executable. They reflect the actual build
time of the target binary/executable (not values produced
at the time the makefiles utility was built and the
appropriate option selected to store them in a text file.)
- most Makefiles should not require adding the new file
src/mdlib.c because util/makedefs.c has a preprocessor
include "../src/mdlib.c" to draw in its contents. As previously
stated though, the Makefile dependency may be required:
makedefs.o: ../util/makedefs.c ../src/mdlib.c
^^^^^^^^^^^^^^^
With 3.7+ aspirations of improving savefile interoperability between 32-bit
and 64-bit builds, as well as between platforms, it is better to not have
the underlying struct/array content be conditional.
This splits off some of the MAIL code into MAIL_STRUCTURES code. In theory,
since MAIL_STRUCTURES is unconditionally included, the macro could
just go away and leave that code unconditional, but this commit doesn't
go that far.
Noticed after building a curses-only binary; configuration setting
"terminal info library" is only of interest as an optional feature
when the build includes tty. There were several other settings that
apply to some interfaces and not others but would be listed if the
feature was defined (possibly after building for an interface which
supported it, then left in place when switching to another which
doesn't).
I left most of those with commented out conditionals in case other
interfaces start supporting them. So you might still get something
like "tiles file in XPM format" for a binary that doesn't support
tiles if USE_XPM has been defined for some reason.
Only changes pm.h content if ENUM_PM is defined when compiling
util/makedefs.c
While NON_PM and LOW_PM could be included, it would require
for the makedefs.c compile, as well as an
around their macro definitions in permonst.h so for now those
particular lines are commented out in makedefs.c
When makedefs generates dat/options for #version, enhance the
formatting of the 'supported windowing systems' section with more
thorough word fill and also emphasize the actual window system names
so that user can tell what value to give to OPTIONS=window_system:%s
when picking one of them. Before and after
Supported windowing systems:
traditional tty-based graphics,
terminal-based graphics using curses libraries, and X11
with a default of tty.
Supported windowing systems:
"tty" (traditional text with optional line-drawing), "curses"
(terminal-based graphics), and "X11", with a default of "tty".
