Angband build system

[Magnate]

Hi all

I have some gripes about the build system:

1. make clean commands should be idempotent - they should have the same result every time. This is true for make clean (which undoes make) but not for make distclean (which undoes configure) or make repoclean (which undoes autogen). In both those cases mk/buildsys.mk and mk/extra.mk are deleted, which then breaks the build system - you cannot run any make commands until you re-run configure to re-create them. I do not understand why the creation of these two .mk files is done by configure, but I suggest that they are not deleted by distclean (even though that then will not strictly undo configure). This way you can still make repoclean after make distclean without things being broken. Even this would leave make repoclean not idempotent (you could only run it once), but it's an improvement.

2. make clean commands should remove ALL .o and .dep files. Currently they only remove the .o and .dep files generated by the current configuration. So if you configure without --enable-sdl2, make [repo/dist]clean does not remove main-sdl2.o or main-sdl2.dep. This is infuriating. Can anyone think of a good reason not to change this?

Rant over.

CC

[Nick]

This sounds reasonable to me - anyone else have opinions?

[backwardsEric]

As for "make distclean" not being idempotent, a more typical autoconf build system which also implements distclean as removing anything that configure generated will have the same problem as Angband's current build system. The difference will be in the error messages. distclean with autoconf would remove all the Makefiles (since each was generated from a Makefile.in by configure) so then when one tries to run "make distclean" again the result is something like

make: *** No rule to make target 'distclean'.  Stop.

. The message with the current build system is something like

Makefile:2: mk/buildsys.mk: No such file or directory
make: *** No rule to make target `mk/buildsys.mk'.  Stop.

The latter is more confusing, but in either case, one won't get anywhere using make until after rerunning configure.

My bias would be to keep "make distclean" as it is because I want something that restores the directories to what they would be if autogen.sh has been run but configure has not. Since autogen.sh is a separate script, having another script (autoclean.sh?) to undo what autogen.sh did (or an option to autogen.sh that would cause it to undo its normal actions) and remove the repoclean target from the Makefiles seems like a reasonable alternative if one wants something that acts like "make repoclean" but won't be broken by "make distclean".

As for "make clean" removing all the object files, that's very reasonable.

[Magnate]

That's a fair point on distclean - happy to leave it as it is. I'm ok with repoclean, since it feels like a hassle to create a separate script to do it. So it means that both distclean and repoclean are one-shot powers, and you need to choose the right one!

[backwardsEric]

Well "make repoclean" is also dangerous for those working from a .tar.gz generated by "make dist": it'll remove the configure script and such a .tar.gz does not include autogen.sh to conveniently rebuild it. That'd be another argument to folding that power into something else (as an option in autogen.sh seems better than a separate script as I've thought about it some more).

[Magnate]

Ah - make dist is now what creates the tarball is it? So it's replaced the old scripts/pkg_src. Good to know! For Debian I have to remove the non-free sound files and Shockbolt tiles, so I have a custom script to do that. But yes, your point about repoclean is well made, I'd be happy to see it change to a function of autogen.

[backwardsEric]

Ah - make dist is now what creates the tarball is it? So it's replaced the old scripts/pkg_src. Good to know!

"make dist" is almost identical to what scripts/pkg_src does. The differences are:

1. It does expect that the name of the generated archive ("OUT") and the directory that the archive unpacks to ("TAG") are set by the user rather than being set internally.
2. It uses scripts/version.sh to set the version string.
3. It excludes the continuous integration scripts, .travis.yml and .github, from the result.

As used by the release workflow on GitHub, "make dist" looks like this where archive_prefix is set from src/Makefile.src's NAME and the version string:

make TAG="$archive_prefix" OUT="$archive_prefix".tar.gz dist

[AnonymousHero]

Seriously: Just write CMakeLists.txt files and be done with it.

It would be much less headache for maintainers and users-who-compile alike. Supporting platforms like Windows is much easier.

[backwardsEric]

Seriously: Just write CMakeLists.txt files and be done with it.

It would be much less headache for maintainers and users-who-compile alike. Supporting platforms like Windows is much easier.

It's been done (except for the macOS and Nintendo builds), mostly by Andres6936, and based on what I've seen on in the forums or on GitHub, it doesn't appear to have made much of an impact. An example is this thread, http://angband.oook.cz/forum/showthread.php?t=11563 , for NarSil. It, like recent versions of Vanilla, has a CMakeLists.txt and uses it, at least on Linux, for some of the continuous integraction scripts on GitHub, but no one seems to be using it (or at least trying to use it) for builds on Windows.

[Magnate]

I'm not an expert on this stuff but I'm told that mixing make and cmake is not a great idea. But the good news is that I found a debian command for creating the right tarball for package building. Things are going well.

[AnonymousHero]

I'm not an expert on this stuff but I'm told that mixing make and cmake is not a great idea. But the good news is that I found a debian command for creating the right tarball for package building. Things are going well.

You are correct. If one goes with e.g. cmake one should go "all in", that is remove the old build system (after an appropriate deprecation period, depending on project, etc.). Anything else is just asking for trouble since you'll then be stuck supporting two systems instead of one sane one.

[Sacksquatch]

It's been done (except for the macOS and Nintendo builds), mostly by Andres6936, and based on what I've seen on in the forums or on GitHub, it doesn't appear to have made much of an impact. An example is this thread, http://angband.oook.cz/forum/showthread.php?t=11563 , for NarSil. It, like recent versions of Vanilla, has a CMakeLists.txt and uses it, at least on Linux, for some of the continuous integraction scripts on GitHub, but no one seems to be using it (or at least trying to use it) for builds on Windows.

I had no idea. I will try this next time I build modern V or one of the variants. I just found the instructions for Narsil after I got curious upon reading this.

This is only a few months old, does this count as a necro? If so, sorry.