Tested:
Ubuntu: make WANT_WIN_TTY=1 WANT_WIN_CURSES=1 resp=1 update
Ubuntu: make WANT_SYSTEM_LUA=1 WANT_WIN_TTY=1 WANT_WIN_CURSES=1 resp=1 update
make CROSS_TO_MSDOS=1 package
make CROSS_TO_AMIGA=1 all
make CROSS_TO_AMIGA=1 package
Set things up so that the Makefile build will look for 'make.prefs'
at the top of the NetHack source tree.
If 'make.prefs' is present, the Makefile build will include it
just ahead of the PRE section of a hints file specified to
sys/unix/setup.sh, or practically the first thing during a
Makefile build if no hints file was specified.
The advantage of using a 'make.prefs' is that instead of putting a
series of Makefile variable value assignments on the command line
each time, like this:
make WANT_WIN_X11=1 WANT_WIN_TTY=1 WANT_WIN_CURSES=1 c2x=1 resp=1 update
you can, instead, put those preferences into make.prefs, like this:
# start of make.prefs
WANT_WIN_X11=1
WANT_WIN_TTY=1
WANT_WIN_CURSES=1
c2x=1
resp=1
# end of make.prefs
Now, my make command just needs to specify a target:
make update
The syntax for checking whether make.prefs exists, and for including
it, is GNU make, or bsd make, specific, so sys/unix/mkmkfile.sh will
insert the correct syntax for the make that is in-use when
sys/unix/setup.sh is executed.
The 'make.prefs' file isn't limited to Makefile variable assignments, and
can contain any valid make syntax for the version of make on your system,
but adding make syntax beyond Makefile variable assignment will cause
your make.prefs file to become specific to that version of make. There
are syntactical differences between GNU make and bsd make, particularly
for directives and conditional tests.
The 'make.prefs' file can potentially eliminate much/all of the manual
editing of distributed repository Makefiles or hints files that you, as
a NetHack developer or builder, might routinely carry out.
You have the option of placing your preference changes in 'make.prefs'
instead.
Related reference for .500 hints file variables:
In the NetHack source tree:
sys/unix/README.hints
On GitHub:
https://github.com/NetHack/NetHack/blob/NetHack-5.0/sys/unix/README-hints
For example, on macOS, where GNU make is being used, and I typically
set things up using the macOS.500 hints file:
sys/unix/setup.sh sys/unix/hints/macOS.500
I might have the following make.prefs in the root of my NetHack source tree:
#---- snip -------
$(info Attention - Using make.prefs)
WANT_MACSOUND=1
resp=1
#---- end-snip ---
For another example, on Linux, where GNU make is being used, and I
typically set things up using the linux.500 hints file:
sys/unix/setup.sh sys/unix/hints/linux.500
I might have the following make.prefs file in the root of my NetHack
source tree:
#---- snip -------
$(info Using make.prefs)
WANT_WIN_X11=1
WANT_WIN_TTY=1
WANT_WIN_CURSES=1
c2x=1
resp=1
#---- end-snip ---
Buffer overflows could occur when interacting with containers while
inputting or outputting many items.
This commit ensures topline updates do not exceed buffer limits by
checking against TBUFSZ.
Issue reported by k21971 on IRC.
In past releases of NetHack, there was a myriad of different hints
files for different operating systems, and even different versions
of operating systems.
It made maintenance a chore, because all the variable hints files
had to be updated for a wanted change, or (as typically was the
case), some lesser-used hints files were left behind and became
outdated.
Instead of going down that road again, this renames
sys/unix/hints/netbsd.500
to
sys/unix/hints/bsd.500
Where things need to differ for a different bsd flavour,
the differences can be shrouded in things like
.if ${WHICHBSD} == "NETBSD"
.else
.endif
This change is being done to make maintenance easier, at the
cost of making the resulting Makefiles a little more complex,
but there won't be as many separate Makefile hints to maintain.
This commit is being done instead of merging pull request #1531
which would add a new sys/unix/hints/openbsd.500 file.
Only tested on NetBSD so far. Please let us know if there's
an issue on other bsd's, and we will attempt to fix thos issues.
Closes#1531
Close
When a random statue or a figurine was generated in special levels,
the gender was not initialized correctly, so you ended up getting
eg. "dwarf ruler"
It now works correctly, and you can still specifically request
a non-gendered version with the montype-parameter.
For example
des.object({ id = "statue" });
des.object({ id = "statue", montype = "dwarf ruler" });
The gnome king statue in minetn-5 was generated as a gnome leader,
obey the gender of the statue name, so generating a statue of
for example "gnome king" and "gnome queen" works correctly.
nhmall