Angband Forums

Angband Forums (
-   Development (
-   -   Voluteer to test VS build solicited (

eastwind January 26, 2020 04:33

Volunteer to test VS build solicited
I have put together a works-for-me build of angband under Visual Studio 2019. The necessary code fixes have now been merged into master.

I'm in the process of putting up a git pull request that will have the solution and project files in it and a document with instructions on how to set them up and use them.

I'd really like to find a volunteer to try to work through the instructions on their machine to make sure they are clear, don't leave anything vital out, and to make sure that the solution and project files I am supplying are portable to environments & machines other than mine.

Somebody who's never used VS before would be a strong test of the instructions. It's supposed to be easy. I hope.

Pagaronn January 29, 2020 12:04

Hi Eastwind, I could try this week-end if it's okay with you. I will like to build and run angband on VS. It's a geeky achievement that I want to get! I tried with Brogue the other day out of curiosity. I will need more time to make it work but if you have a doc and steps to follow for Angband, I'll be glad to help.

eastwind January 30, 2020 02:09

Great, I checked in everything you'll need, it's under src\win\vs2019. The doc is the "Building with Visual Studio 2019.docx" file (that's a MS word file, hopefully you've got a reader for it), and the other files in that folder are the rest of what you need, as described in the docx, except for VS and the git plugin which you download & install off the web.

Please post any questions you have to this thread (so if others follow they can see the answers) and I'll try to check in often over the weekend to respond with alacrity if you run into anything.

Pagaronn February 2, 2020 04:59

Where is the link? Not sure where to look! :-)

eastwind February 2, 2020 16:48

There's no link to instructions on web page, the instructions are checked into the repository. Maybe I'll get them on the wiki eventually, but for now I was looking for a volunteer already familiar with building angband using other tools who was willing to test using the Visual Studio tools.

Today's the superbowl, so I might not be able to answer questions later.

Pagaronn February 3, 2020 23:47

I have no idea where to start. You do a have a link to the project where I can download it?

I have VS2017 for work. I would check if I can compile with this version.

Pete Mack February 4, 2020 00:22

It is a git project:

Powershell> git clone

(Or command prompt window or whatever. But it requires git.)

eastwind February 4, 2020 06:31

You can clone to a temporary location, then read the doc at src\win\vs2019"Building with Visual Studio 2019.docx".

Clone the master, not 2.4.0., or the directory won't be present.

EpicMan February 8, 2020 22:08

I got it to work on Windows 10 with Visual Studio 2019 Community Edition (i.e. the free one). Played a bit and verified new game, save and load work. Good work, I have not been able to successfully build Vanilla in VS until now.

One small change,I might suggest would be to edit the .sln file line 6 to replace "Angband\Angband.vcxproj" with "Angband.vcxproj" to allow the project and solution files in the same directory. Then you don't need to create any additional folder structures, you just copy them all into the "angband" directory and run it from there.

AnonymousHero February 14, 2020 21:40

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 :(

Nick February 14, 2020 23:21


Originally Posted by AnonymousHero (Post 143070)
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 February 15, 2020 00:20

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 February 15, 2020 18:18

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 February 15, 2020 22:22

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 February 16, 2020 04:23

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 February 16, 2020 21:13

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

Regards, Willem.

Gwarl February 18, 2020 22:51

All I ask is that nobody removes the ability to simply

make -f Makefile.std
from anything. Please.

Pagaronn February 19, 2020 13:09

follow up
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 February 21, 2020 13:31


Originally Posted by eastwind (Post 143084)
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 May 4, 2020 08:31

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.
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

Gauss May 4, 2020 12:52


Originally Posted by AnonymousHero (Post 143070)
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 :(

I've been working on it for a week now. Still trying to get it build but i have currently a lot of assignments and work.

All times are GMT +1. The time now is 09:01.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.