Removing autoconf/configure in Vanilla

[backwardsEric]

For the forseeable future, autotools/configure will be maintained as a way to build Angband. If you are compiling Angband, I encourage you to try out cmake and report any problems or suggestions for improvements you have either in a thread here in the Vanilla or Development forums or on https://github.com/angband/angband/issues . Since some (all current?) versions of Visual Studio have cmake support, it would be especially interesting to hear how pointing Visual Studio at Angband's CMakeLists.txt works as a way to import Angband as a project.

[backwardsEric]

I don't have a ton of experience with cmake, but one thing I appreciate about the current autotools build is that by massaging CFLAGS/LDFLAGS I've been able to get Angband to build correctly on many different systems (including some less common ones like NetBSD, HaikuOS, etc.).

When cmake configures the build system, the typical environment variables, CC, CFLAGS, and LDFLAGS, can be used to set the compiler, compiler options, and linker options. cmake's documentation about that is at https://cmake.org/cmake/help/latest/...riables.7.html . In that respect, it is much like autotools. One difference is that there are cmake variables which, if set on the command line, would override CC, CFLAGS, or LDFLAGS.

Is there a specific problem with the existing autotools setup that this is fixing?

The author gives the rationale in one of the responses on the conversation on the pull request. There are some things, mainly relevant when building for Windows, that the current setup for cmake does better than the current setup for autotools: it can readily use external png and zlib libraries (the autotools setup uses the ones packaged in src/win) and it can be easier to set up static linking of external libraries (that part is largely due to the reliance on pkg-config; the implementation with cmake is much easier to maintain than the previous src/Makefile.msys2.sdl2 which statically linked SDL2 under the MSYS2 environment on Windows).

[Nick]

I would strongly recommend people interested in this to look at the conversation on the pull request linked in Eric's original post.

In particular, this is necessary because the originator of the pull request has been unable to register for the forums (attention Gwarl!).

[d_m]

I don't have a ton of experience with cmake, but one thing I appreciate about the current autotools build is that by massaging CFLAGS/LDFLAGS I've been able to get Angband to build correctly on many different systems (including some less common ones like NetBSD, HaikuOS, etc.).

Is there a specific problem with the existing autotools setup that this is fixing? Is this just the author's preference?

Angband has a long history of supporting many ways to build the code (originally a big pile of Makefiles), so I don't see a problem with including both cmake and autotools support. If that _is_ a problem, I don't know why autotools needs to be the one to go.

But I'm pretty far from active, so I will defer to those actually writing the code these days.

[Nick]

The idea makes me uneasy, but possibly only because autotools is what I'm used to, and I'm far from being an expert.

[backwardsEric]

A pull request, https://github.com/angband/angband/pull/6560 , has been submitted to remove autoconf/configure as a way to compile Vanilla Angband. If you do use autoconf/configure to compile Vanilla and are not at all interested in using cmake instead or have tried Vanilla's CMakeLists.txt and found it insufficient for what you want, I'd be interested to know why you would like Vanilla to retain autoconf/configure.

Personally, my concerns about completely dropping autoconf/configure are:

• Vanilla's CMakeLists.txt is heavily reliant on pkg-config to locate external software. I know of one case where that causes it to miss available software (the version of the ncurses library included with Xcode's macOS SDK; admittedly, Vanilla's configure also has problems detecting it). I do not have enough experience with pkg-config and CMake to know how easy it is to get it to use software installed in a non-standard location, like one's home directory.
• There has been little feedback, in terms of reported problems or bug fixes, from the community about Vanilla's CMakeLists.txt. So, I do not know if it meets what the community expects when compiling Vanilla.