Voluteer to test VS build solicited

[Nick]

Originally Posted by AnonymousHero

This is exactly why Angband should just bite the bullet and move to CMake. It'll happily generate solution files, etc. I've offered to help before, but it fell on deaf ears

So we have had our current build system since well before my time, and it works for all the things we need it to work for (basically), and this stuff is not my strong suit so I'm disinclined to (or maybe afraid to) change it.

If anyone who knows more about the current system wants to discuss the pros and cons, I'm happy to watch.

[Pete Mack]

Nick-
The current system was done by yours truly circa 3.1, not all too many years before your time. I cleaned up a bunch of standard makefiles and added the include files for portability. That said, I truly don't understand autoconf, which seems like black magic to me.

[AnonymousHero]

Oh, it works and has been working except when it doesn't :|... See title of this thread.

Advantages for CMake are:

• isn't automake/autoconf. I'm sure Pete will back me up on this... Auto* is a hellscape of bizarre compatibility nonsense going back to SunOS and similarly absurdly outdated/dead platforms. It's also totally inscrutable because it's basically a bizarre blend of m4 + Shell script, and it requires EXTREME care to be compatible with POSIX shell.
• can generate makefiles, ninja files, IDEs like qtcreator (and VS code?) use and understand these files. No idea if VS code understands CMake files, but at least CMake can generate Solution files, which was a big point in this thread. (Committing solution files to the repo. That's an antipattern unless you're purely going to use MSVC/whatever.)

(I'm sure I missed out on something... just addressing the points raised in response to my post.)

[Pete Mack]

Took a look at the CMake examples. Looks very nice. I just did as much as I could with ordinary makefiles--making them reasonably clean and as portable as possible. I also don't like ./configure, either. Real mystery when it doesn't work; I'd much rather a system that knows the details of target OS, and doesn't make guesses.

[eastwind]

I don't think the fact that I made angband build with VS is a good argument for switching to CMake. Rather, it's a good argument for not using CMake. Anyway, CMake is a different discussion for a different thread.

The argument about flattening the VS build hierarchy so that the solution and project sit in the same directory comes up every single time (not just Angband, it comes up *every* time you create a VS build for something that had another build first). I believe there are several good reasons for using the two-level directory hierarchy, and no *good* reasons for not using it.

First is the way VS handles 'intermediate' files, those files created by the build which are not necessary to 'ship', for example, all the .obj files. If you flatten the hierarchy, by default the intermediate output directory ends up being the same as the final output directory, and the stuff you need to ship gets mixed with the stuff you don't. That is, the IntermediateOutputDirectory ends up being the same as the OutputDirectory, and issues ensue. You can override those, but then other issues ensue that you have to work through. I have been down this road before, and it's more difficult overall.

Another reason is that, by design, a VS 'Solution' is intended to encapsulate multiple different projects related to the same larger 'thing'. An example of this is in fact used by Angband - the test file stuff. I didn't make that work, but if I had wanted to, there would be a Test.vcxproj in a Test folder underneath the solution folder, and Test would be a peer to the Angband folder with the Angband.vcxproj. The way it is set up now, if somebody wants to come along and create some kind of add-on executable that builds separately from Angband.exe they can easily do so, within the VS model.

It's important to understand that the VS build system model uses a 1:1 mapping between a .vcxproj and an .exe (or .dll) output file. If you want to ship multiple executables, the VS model is you have one project per executable that you want to ship. The build system is set up to build all the stuff associated with a single executable (like debug symbol files, map files, etc etc) along with the executable, but trying to get a .vcxproj to build two .exes just doesn't work unless you simply don't use the VS MSbuild and have it run a makefile instead, in which case you lose a lot of the goodness of VS.

You don't, under the VS build model, want to put multiple .vcxproj's in the same folder, because then the two projects try to build intermediates into the same subfolders of that, and chaos ensues. So the flat hierarchy only works if you only *ever* want to build a single executable. So if you start off that way (with a flat hierarchy), you close off future options.

You can make a single level hierarchy work. You're starting with something designed to work one way and bashing it into another form, and with enough bashing you can get it to work, at least until some kind of new change comes along (either in your requirements, or in VS). It's more work to make it work, you have a less-ideal build when you're done, and it's more brittle. But it satisfies the people who really want to 'be like' make. The cost of doing this, both in getting it working in the first place and in using it and maintaining it over the long haul, is really far beyond the benefit. I don't think wanting to 'be like' the other builds is a good reason for doing it, given the costs. It's not genuinely simpler.

I used VS to build various projects extensively from 2005-2016, and I have gone down the 'flat build' path a time or two on my own, thinking it would be simpler and easier for a given little project, only to end up changing back to a multi-level build later for at least two different solutions. Never again. Sooner or later you always end up paying a big penalty for not coloring within the lines on this issue.

[Siemelink]

Hi Eastwind,
thanks for the docs, I managed to compile as well. Now I need a purpose!

Regards, Willem.

[Gwarl]

All I ask is that nobody removes the ability to simply

make -f Makefile.std

from anything. Please.

[Pagaronn]

Sorry eastwind, I did not do any followup since my offer to help. I felt overwhelm to get the project - I was not sure how so I went back at playing UnAngband instead with my free time.

[AnonymousHero]

Originally Posted by eastwind

I don't think the fact that I made angband build with VS is a good argument for switching to CMake. Rather, it's a good argument for not using CMake.

The mere fact that you even had to work to make Angbuild build with VS is an argument for CMake (or whatever other non-make non-auto* system that is actually somewhat sane -- I only mention CMake because I'm familiar with it and have used it quite happily with T2. Most IDEs I've tried also have decent-to-good support for it -- which is not the case for make-based systems.). It should have just worked out of the box.

... but never fear. I have no intention of pressing the issue. (Nor could I.) I just wanted to mention that these issues are indeed soluble and should be non-issues.

[WindLord]

I successfully got your image to compile and run. It took a couple times and finally matched your directory structure.
The instructions seem to show two ways to do stuff. One is use directly from the GIT master and the other is to use your VS project.

Your build seems slower than the Windows EXE available for download.

Do you know if your image includes the update for the Quiver changes? I play as Ranger and this is of interest to me.

Thank you for getting this up.
Rick
PS: I downloaded the Master, and all compiled. But when I try to run it, the different windows come up and stay for about two seconds then the program shuts down.
Figure I overwrote a file that should not have been changed. And suggestions where to start looking?
Thank you