Compiling Frogcomposband nightly w/ ncurses on Fedora 36

[HugoVirtuoso]

I have an issue that pertains to subject line. I have Fedora 36 with ncurses6. When I do ./configure, it keeps saying missing Curses libraries. This is probably because its code keeps pointing to ncurses5. Apparently, Fedora doesn't let me install ncurses5 in parallel with the already installed ncurses6. Any suggestions?

[backwardsEric]

Assuming ncursesw6-config is in your path, you could use

./configure NCURSES_CONFIG=`which ncursesw6-config` [put the other configure options you want here]

. That'll bypass the part of the configure script which searches for ncursesw5-config. If ncursesw6-config isn't in your path but you know where it is, replace "`which ncursesw6-config`" in the command above with the full path to ncursesw6-config.

[HugoVirtuoso]

Feedback was very helpful. It completely resolved the ncurses5 issue, specifically because I now know I actually don't need ncurses5 at all anymore.

[HugoVirtuoso]

What do these warnings mean? They don't seem to impact my FCPB compile at all.

amdbravo15@localhost ~/frogcomposband $ sh autogen.sh
*info* running aclocal (-I m4)
*info* running autoheader
*info* running autoconf
configure.ac:9: warning: $as_echo is obsolete; use AS_ECHO(["message"]) instead
m4/buildsys.m4:179: BUILDSYS_TOUCH_DEPS is expanded from...
configure.ac:9: the top level
configure.ac:83: warning: The macro `AC_TYPE_SIGNAL' is obsolete.
configure.ac:83: You should run autoupdate.
./lib/autoconf/types.m4:776: AC_TYPE_SIGNAL is expanded from...
configure.ac:83: the top level
configure.ac:228: warning: The macro `AC_TRY_RUN' is obsolete.
configure.ac:228: You should run autoupdate.
./lib/autoconf/general.m4:2997: AC_TRY_RUN is expanded from...
acinclude.m4:326: AM_PATH_NCURSESW is expanded from...
configure.ac:228: the top level
configure.ac:228: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:228: You should run autoupdate.
./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
acinclude.m4:326: AM_PATH_NCURSESW is expanded from...
configure.ac:228: the top level
configure.ac:257: warning: The macro `AC_TRY_RUN' is obsolete.
configure.ac:257: You should run autoupdate.
./lib/autoconf/general.m4:2997: AC_TRY_RUN is expanded from...
acinclude.m4:156: AM_PATH_SDL is expanded from...
configure.ac:257: the top level
configure.ac:257: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:257: You should run autoupdate.
./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
acinclude.m4:156: AM_PATH_SDL is expanded from...
configure.ac:257: the top level
amdbravo15@localhost ~/frogcomposband $ autoupdate
configure.ac:83: warning: your code may safely assume C89 semantics that RETSIGTYPE is void.
Remove this warning and the `AC_CACHE_CHECK' when you adjust the code.
amdbravo15@localhost ~/frogcomposband $

Side note: I've moved to Gentoo. With Gentoo, I already was able to ./configure NCURSES_CONFIG=`which ncursesw6-config` with no problem just for ncurses purposes alone.

[HugoVirtuoso]

Later on, when I do make install as 'root' I get the following (especially towards the bottom):

localhost /home/amdbravo15/frogcomposband # make install
Entering directory src
make[1]: Entering directory '/home/amdbravo15/frogcomposband/src'
Installing frogcomposband...
Successfully installed frogcomposband.
make[1]: Leaving directory '/home/amdbravo15/frogcomposband/src'
Leaving directory src
Entering directory lib
make[1]: Entering directory '/home/amdbravo15/frogcomposband/lib'
Entering directory apex
make[2]: Entering directory '/home/amdbravo15/frogcomposband/lib/apex'
make[2]: Leaving directory '/home/amdbravo15/frogcomposband/lib/apex'
Leaving directory apex
Entering directory bone
make[2]: Entering directory '/home/amdbravo15/frogcomposband/lib/bone'
make[2]: Leaving directory '/home/amdbravo15/frogcomposband/lib/bone'
Leaving directory bone
Entering directory data
make[2]: Entering directory '/home/amdbravo15/frogcomposband/lib/data'
Installing delete.me...
Successfully installed delete.me.
make[2]: Leaving directory '/home/amdbravo15/frogcomposband/lib/data'
Leaving directory data
Entering directory edit
make[2]: Entering directory '/home/amdbravo15/frogcomposband/lib/edit'
Installing a_info.txt...
/usr/bin/install: 'a_info.txt' and '/home/amdbravo15/frogcomposband/lib//edit/a_info.txt' are the same file
Failed to install a_info.txt!
make[2]: *** [../../mk/buildsys.mk:437: install] Error 1
make[2]: Leaving directory '/home/amdbravo15/frogcomposband/lib/edit'
make[1]: *** [../mk/buildsys.mk:432: install] Error 2
make[1]: Leaving directory '/home/amdbravo15/frogcomposband/lib'
make: *** [mk/buildsys.mk:432: install] Error 2
localhost /home/amdbravo15/frogcomposband #

Any suggestions? I would prefer to let the make install replace those files, but it can't...

Yes, the --with-no-install suffix to ./configure was indeed my intention.

[backwardsEric]

The warnings about obsolete AC_* macros from autoconf 1.* are something I first saw with autoconf 2.70. autoconf does include a utility, autoupdate, to rewrite configure.ac to avoid those macros; that's what was used to fix up Vanilla Angband to avoid those warnings (the relevant changes are here, https://github.com/angband/angband/c...80bd996395df43 ).

As for "make install" not working when it was configured with "--with-no-install", I'm not surprised. Everything is already in the right place (well maybe you prefer the executable to be in the top level directory rather than src). I'd recommend just using "make" to build everything.

Vanilla Angband incorporated a change to accommodate people running "make install" for a "--with-no-install" build, but that amounts to some extra logic in the build system to skip most of the extra steps that "make install" would normally do. If someone is really keen on incorporating that into other variants using the mk build system, they can see what was done for Vanilla Angband here, https://github.com/angband/angband/c...a255abc60965e6 .

[HugoVirtuoso]

The warnings about obsolete AC_* macros from autoconf 1.* are something I first saw with autoconf 2.70. autoconf does include a utility, autoupdate, to rewrite configure.ac to avoid those macros; that's what was used to fix up Vanilla Angband to avoid those warnings (the relevant changes are here, https://github.com/angband/angband/c...80bd996395df43 ).

Here I'm trying to use sh autogen.sh on a git clone of the most recent FrogComposband (FCPB) nightly. FrogComposband is a a descendent of PosChengband whose dev (Chris Kousky) wrote the build instructions probably in 2014, which predates today's Angband code cleanup by years. Wrt to sh autogen.sh and/or autoupdate, what should I do differently? Should I use autoupdate and then omit the sh autogen.sh step? Looks like another code change Sideways / rodent could make to his Frogcomposband fork down the road.

The last time I compiled FCPB nightly on Fedora (with the ncurses workaround), I skipped the autogen.sh step completely. I skipped it initially not knowing if it was needed. I did solely these latter three steps: ./configure, make, and make install (because back then, I intended to install it as a program for my Fedora login, not just the current folder). When I did those steps, I succeeded with a working FCPB binary then

[backwardsEric]

Wrt to sh autogen.sh and/or autoupdate, what should I do differently? Should I use autoupdate and then omit the sh autogen.sh step? Looks like another code change Sideways / rodent could make to his Frogcomposband fork down the road.

I'd just run autogen.sh as normal and live with the warnings. If you wanted to submit a patch to sideways to get rid of the warnings, then you might use autoupdate in the process.

The last time I compiled FCPB nightly on Fedora (with the ncurses workaround), I skipped the autogen.sh step completely. I skipped it initially not knowing if it was needed. I did solely these latter three steps: ./configure, make, and make install (because back then, I intended to install it as a program for my Fedora login, not just the current folder). When I did those steps, I succeeded with a working FCPB binary then

If I had to guess, it's likely that whatever install script/binary is in the path is implemented differently on Gentoo than on Fedora, and that explains the different result from "make install" on the two systems.

[HugoVirtuoso]

If I had to guess, it's likely that whatever install script/binary is in the path is implemented differently on Gentoo than on Fedora, and that explains the different result from "make install" on the two systems.

In the Gentoo case, I intentionally used --with-no-install. In Fedora, I didn't use that option. I'll check later if the default Gentoo install directory implementation (i.e. without --with-no-install) works by design (i.e. default path instead of current directory). Though, I'm sure it will.