Commit Graph

1023 Commits

Author SHA1 Message Date
G. Branden Robinson
a8253dda00 Update Unix hints to revise groff detection
The existing detection logic was not working on any groff since at least
1.22.3 (November 2014), as could be seen by uncommenting the "$(info
...)" line.  The regex used to match "nroff --version" output was
insufficiently flexible.

Fixes:
$ (cd doc && rm -f Guidebook && PATH=$HOME/groff-1.22.3/usr/bin:/bin make Guidebook) | grep NROFF
NROFFISGROFF=
$ (cd doc && rm -f Guidebook && PATH=$HOME/groff-1.22.4/usr/bin:/bin make Guidebook) | grep NROFF
NROFFISGROFF=
$ (cd doc && rm -f Guidebook && PATH=$HOME/groff-1.23.0/usr/bin:/bin make Guidebook) | grep NROFF
NROFFISGROFF=
$ (cd doc && rm -f Guidebook && PATH=$HOME/groff-HEAD/usr/bin:/bin make Guidebook) | grep NROFF
NROFFISGROFF=

Use a different approach in Make to recording groff detection.  Use
"grep -c" (which is POSIX-conforming) to count the number of matches so
that we can use the contents of the Make macro `NROFFISGROFF` as a sort
of Boolean, which reads more idiomatically (in my opinion).

Further, instead of trying to lexically analyze a matched line in the
output of "nroff --version" and parse components of a version number out
of it, use GNU troff's built-in facility for extracting its minor
version number by storing the output of a tiny *roff document that
reports that datum (and nothing else).

Ignore warnings in category "scale" in any version of groff, because the
`tmac.n` macro package provokes them.

Clarify comments.
2026-02-07 05:00:22 -06:00
nhmall
8b6ba69fd8 linux.370 hints: validate sysconf GDBPATH
With sys/unix/hints/linux.370, if GDBPATH doesn't exist, comment out
the GDBPATH line in sysconf during 'make install' or 'make update'.

[ macOS apparently uses sys/unix/hints/macosx.sh to do its sysconf manipulation,
so there is no corresponding change for sys/unix/hints/macOS.370 ]

Closes #1477
2026-01-15 17:02:38 -05:00
Pasi Kallinen
d0b9846367 Move item actions into separate src file
Haven't tested compilation on Windows and VMS ...
2026-01-11 14:46:25 +02:00
Pasi Kallinen
99b893c786 Add a new bigroom variant "pillars"
Some variants have a bigroom variant called "Mines of Moria";
this one is very much that, but has several different arrangements
of the pillars.
2026-01-09 19:39:45 +02:00
nhmall
642cf9a93e bump Lua references from 5.4.6 to 5.4.8 2026-01-04 11:12:50 -05:00
nhmall
c12344cd48 build dos in CI but skip faltering Terminus font steps 2025-11-10 12:56:49 -05:00
nhmall
2c747b079e revert some CI test changes 2025-11-10 09:19:47 -05:00
nhmall
efbc0d8f8f more troubleshooting Terminus font use in CI environment 2025-11-10 08:52:06 -05:00
nhmall
4dfdeb8e92 follow-up in seldom-used places 2025-11-08 14:53:50 -05:00
Michael Allison
58c7d2fb3e macOS QT6 doc tidbit 2025-11-05 13:20:45 -05:00
Hector Denis
4e29db079b Fix QTCXXFLAGS and WINLIB when compiling with WANT_WINT_QT6.
The previous code made incorrect assumptions about Qt6's file hierarchy. Reuse automatic configuration (with pkg-config) for Qt5, and replace '5' by '6'.
Also fix a typo in multiw-2.370.
2025-11-05 18:20:55 +01:00
nhmall
b72d4af837 correct a few minor typos in sys 2025-10-25 10:14:28 -04:00
nhmall
f636749ea2 suppress dozens of new compiler warnings with clang-21
Turn off default -Wdeprecated-octal-literals warning with clang-21

One example of many:

In file included from objects.c:22:
../include/objects.h:137:1: warning: octal literals without a '0o' prefix are deprecated
      [-Wdeprecated-octal-literals]
  137 | PROJECTILE("arrow", NoDes,
      | ^
../include/objects.h:119:48: note: expanded from macro 'PROJECTILE'
  119 |            BITS(kn, 1, 1, 0, 0, 1, 0, 0, 0, 0, PIERCE, sub, metal), \
      |                                                ^
../include/objclass.h:79:18: note: expanded from macro 'PIERCE'
   79 | #define PIERCE   01 /* pointed weapon punctures target */
      |                  ^
In file included from objects.c:22:
../include/objects.h:140:1: warning: octal literals without a '0o' prefix are deprecated
      [-Wdeprecated-octal-literals]
  140 | PROJECTILE("elven arrow", "runed arrow",
      | ^
../include/objects.h:119:48: note: expanded from macro 'PROJECTILE'
  119 |            BITS(kn, 1, 1, 0, 0, 1, 0, 0, 0, 0, PIERCE, sub, metal), \
      |                                                ^
../include/objclass.h:79:18: note: expanded from macro 'PIERCE'
   79 | #define PIERCE   01 /* pointed weapon punctures target */
      |                  ^
In file included from objects.c:22:
../include/objects.h:143:1: warning: octal literals without a '0o' prefix are deprecated
      [-Wdeprecated-octal-literals]
  143 | PROJECTILE("orcish arrow", "crude arrow",
      | ^
../include/objects.h:119:48: note: expanded from macro 'PROJECTILE'
  119 |            BITS(kn, 1, 1, 0, 0, 1, 0, 0, 0, 0, PIERCE, sub, metal), \
      |                                                ^
../include/objclass.h:79:18: note: expanded from macro 'PIERCE'
   79 | #define PIERCE   01 /* pointed weapon punctures target */
      |                  ^
2025-10-22 12:52:10 -04:00
nhmall
349fbe93b1 less verbose compiler command lines during build
If using hints file sys/unix/hints/linux.370 or sys/unix/hints/macOS.370
allow the majority of the boilerplate compile switches to reside in a
compiler response file, instead of on the command line.

Include one of the following on your make command line:

make response=1
  or
make resp=1

It can be combined with other make command line options. See
sys/unix/README-hints for further information about those.

The response files that it uses are:
    CC   (clang or gcc)    src/nethack_cc.rsp
    CXx  (clang++ or g++)  src/nethack_cxx.rsp

Note: I think the reduced clutter should actually become the default,
and the override should be noresponse=1 to NOT use it, but I'm
not sure how others feel, so for now, it requires
    make resp=1
Feedback on whether that should become the default or not
is welcome.

Tested on Linux with gcc-15 and on Linux with clang-20.

I haven't had a chance to test it on macOS yet.
2025-09-07 12:50:54 -04:00
nhmall
6c3e70ad77 remove stray tabs from *.c files and config.h 2025-08-19 08:35:39 -04:00
Michael Allison
b0076decae more Xcode follow-up 2025-08-06 14:25:50 -04:00
Michael Allison
2b399d1739 more follow-up (for Xcode) 2025-08-06 14:12:10 -04:00
nhmall
75a2a61653 some Makefile follow-up 2025-08-06 13:51:22 -04:00
nhkeni
65774372e6 Merge branch 'NetHack-3.7' of https://rodney.nethack.org:20040/git/NHsource into NetHack-3.7 2025-07-11 15:44:43 -04:00
nhkeni
03415bc595 fix typo 2025-07-11 15:44:23 -04:00
nhmall
6c22e7af45 attempt to ensure the correct curses.h is used on Linux
OpenSUSE Tumbleweed ncurses 6.5 requires the one in
/usr/include/ncursesw/curses.h, if ncursesw is being used.

Otherwise, several needed function prototypes are not there.

Fixes #1427
2025-07-10 22:44:56 -04:00
nhmall
b4f2ef853a add more fallback values to allow basic build to proceed 2025-07-07 12:43:27 -04:00
nhmall
69cf9ad689 aim for successful build even without using hints file 2025-07-07 10:32:47 -04:00
nhmall
34b42d2354 recent qt6 requires c++20
There are warnings within the qt6 header files if c++20 is not used, for example:

usr/include/x86_64-linux-gnu/qt6/QtCore/qfuturesynchronizer.h:21:5: warning: use of the 'nodiscard' attribute is a C++20 extension [-Wc++20-attribute-extensions]
   21 |     Q_NODISCARD_CTOR_X("Use future.waitForFinished() instead.")
      |     ^
/usr/include/x86_64-linux-gnu/qt6/QtCore/qcompilerdetection.h:972:43: note: expanded from macro 'Q_NODISCARD_CTOR_X'
  972 | #    define Q_NODISCARD_CTOR_X(message) [[nodiscard(message)]]
      |                                           ^
1 warning generated.

qmake6 --version
QMake version 3.1
Using Qt version 6.8.3 in /usr/lib/x86_64-linux-gnu
2025-06-29 11:59:07 -04:00
Pasi Kallinen
8d8867007f Typofix 2025-06-27 00:28:27 +03:00
nhmall
cb12423a2e sys/unix/Makefile.utl update for sfctool 2025-06-02 21:52:38 -04:00
Michael Allison
2414e56646 Xcode project update to include: cfgfiles.c sfbase.c 2025-06-01 22:04:44 -04:00
nhmall
66007e6783 remove duplicated code from sfctool.c, sftags.c
Link with hacklib to provide them instead
2025-06-01 15:32:55 -04:00
nhmall
956c826223 Makefile.src bit 2025-05-26 13:34:31 -04:00
nhmall
a654d08c3b save/restore changes - part 3
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
2025-05-25 20:38:17 -04:00
nhmall
f4a6da2e52 save/restore changes - part 2
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.
2025-05-25 15:03:13 -04:00
nhmall
78a4fd2fb8 split config file processing into its own src file 2025-05-21 23:58:01 -04:00
nhmall
8ac31b24f6 libnh build
The macOS.370 has not yet been tested, but it is patterned after
the linux.370 changes.
2025-05-12 08:45:26 -04:00
nhmall
8f38267775 use documented SIG_RET_TYPE for Linux with gcc 2025-04-20 13:13:30 -04:00
nhmall
dcb0fc7654 remove unused target from Makefile.utl 2025-04-15 20:03:28 -04:00
nhmall
5560bdb27c msdos recover 2025-04-15 19:53:50 -04:00
nhmall
44af2a96a5 recover utility updates 2025-04-15 18:02:44 -04:00
nhmall
3ed63f9be4 more Xcode cleanup 2025-03-19 21:20:39 -04:00
nhmall
f30780e42e clean up absolute paths 2025-03-19 21:16:46 -04:00
nhmall
872a9778ed Xcode project update 2025-03-19 19:26:27 -04:00
nhmall
1f99638bbf ren nhconst.h -> weight.h
The speed related values were not used, except for NORMAL_SPEED,
which has been moved back to permonst.h
2025-03-19 17:14:07 -04:00
nhmall
a943c4c10b replace some weight-related magic numbers
adds a header file include/nhconst.h  (I'm open to a better name)
2025-03-19 13:29:58 -04:00
nhmall
b169b79d36 dump monster and obj weights using --dumpweights 2025-03-15 19:55:49 -04:00
nhmall
dfe2a967fc fix a recent typo 2025-03-13 07:40:20 -04:00
nhmall
4a67caf3d7 document musl=1 in README-hints 2025-03-11 10:27:18 -04:00
nhmall
fbb8ef2fa6 follow-up: set STRIPBS in Makefiles 2025-03-10 17:18:58 -04:00
nhmall
bddca2ded5 musl libc build, rather than glibc
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
2025-03-10 17:14:24 -04:00
Keni
372ebd9d80 NOSTATICFN/NONOSTATICFN typos and logic fixes 2025-02-17 11:50:55 -05:00
nhmall
f1be2eaffa add --dumpmongen to view mongen_order[] array 2025-02-14 09:38:29 -05:00
nhkeni
cfe39900ca Demo for downloading formatted docs
Written for MacOS, more useful for Windows (but I'm not writing that).
2025-01-31 21:48:15 -05:00