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 ---
Fixes four issues that prevented `make WANT_LIBNH=1 all` from producing
a libnh.a that could be linked into a host program on macOS. Before
these patches, it built but the resulting archive was unusable: macOS
ld errored on a nested liblua archive member, was missing date.o and
hacklib symbols (`populate_nomakedefs`, `eos`, `lcase`, `mungspaces`,
...), and had duplicate definitions of `main`, `whoami`, etc.
Specific changes:
1. sys/libnh/libnhmain.c: drop `static` on `whoami()`. src/earlyarg.c
declares it `extern` and calls it from `scores_only()`; the static
makes it file-local and that reference goes unresolved.
2. sys/libnh/libnhmain.c: gate the emscripten-only code in get_nhuuid
with `#ifdef __EMSCRIPTEN__` instead of `#ifdef NHUUID`. The macOS
hints define NHUUID for the libnh build (they did so unconditionally
before NO_NHUUID even existed), so on native builds the compiler
tried to call `emscripten_run_script_int` / `_string` and failed
with implicit-function-declaration errors. __EMSCRIPTEN__ is the
real signal for "this is being cross-compiled to WASM."
3. sys/unix/hints/macOS.500: in the WANT_LIBNH block, add an explicit
`recover: lua_support` dependency (gated by MAKEFILE_TOP). When
$(GAME) is overridden to empty, the regular `recover: $(GAME)` chain
no longer triggers `lua_support`, so include/nhlua.h never gets
generated and recover.c's transitive #include of hack.h fails.
4. sys/unix/hints/macOS.500: rewrite the libnh.a rule. The previous
`ar rcs libnh.a $(HOBJ) $(LIBNHSYSOBJ) liblua-$(LUA_VERSION).a` had
four problems: (a) ar archives liblua.a as a single opaque member
that macOS ld can't dereference, (b) date.o (DATE_O, kept separate
from HOBJ) was never archived, so `populate_nomakedefs` and
`nomakedefs` were missing, (c) hacklib.a was likewise omitted, and
(d) HOBJ already contains $(SYSOBJ) (with unixmain.o) and $(WINOBJ)
(the tty windowport), which duplicated symbols from libnhmain.o /
winshim.o.
The fix uses `libtool -static` so hacklib.a and liblua's archive
have their members merged rather than nested, depends on $(LUALIB)
so lua_support runs first, includes $(DATE_O) and $(TARGET_HACKLIB),
and uses $(filter-out $(SYSOBJ) $(WINOBJ),$(HOBJ)) to drop the
duplicates.
Verified by clean rebuild on macOS 26 (arm64, Apple clang 17):
make spotless
make fetch-Lua
make WANT_LIBNH=1 all
and link-tested with a tiny harness that calls
shim_graphics_set_callback() against the resulting libnh.a.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
nhmall