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 ---
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
All the files in outdated are mostly source as they were prior to
the move to the outdated part of the NetHack tree. They are left
there in case somone wants to try to resurrect a port.
They are not meant to be compiled, or used as-is.
A remnant hard-coded 370 was in package.nmake.
Note: The errant file was not used to construct the official
binaries. Those were done using sys/windows/Makefile.nmake.
Closes#1525
Add Makefile support for an optional AMIGPKGSEQ to
append a suffix to the Amiga binary, without having to
rename the zip file manually after the
make CROSS_TO_AMIGA=1 package
step.
Bug report stated:
"If 'mention_decor' is set in config file or NETHACKOPTIONS,
starting the game tells you that you are standing on stairs
which lead out of the dungeon. But if you also start the
tutorial, you won't be on those stairs--they won't even exist
until the tutorial is exited.
The stairs message can't be suppressed until the program
knows whether the tutorial will be entered, and since
prompting is one of the ways to decide that."
What this does:
Don't heed mention_decor option during the primary rcfile()
processing.
Do heed it after the tutorial.
Note:
If mention_decor is expected to actually be active during the
tutorial, then the rcfile_only_this_option(opt_mention_decor)
likely has to be moved to a different line, which should be
easy enough.
The previous fix, while valid, still prompts for input during early
options processing if stdin is a tty. It really shouldn't be doing
that during early options such as --showpaths, so alter the placement
of the program_state.earlyoptions flag within *main().
GitHub issue https://github.com/NetHack/NetHack/issues/1513
Starting a new game, at the
'Shall I pick character's race, role, gender and alignment for you? [ynaq]'
prompt, the game shows as 'Version 5.0.0-0 Unix Work-in-progress'
but then once the game has started and you check #version you see
the correct 'Unix NetHack Version 5.0.0-0 post-release' feedback.
Closes#1513
Try using emscripten_run_script_string("crypto.randomUUID()");
I need to commit this to the repository to test it elsewhere.
If there isn't a revert shortly after this, it must have at least
built without issue.
nhmall