Voluteer to test VS build solicited

[eastwind]

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]

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]

Wonderful

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]

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

[eastwind]

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]

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]

It is a git project:

Powershell> git clone https://github.com/Eastwind921/angband

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

[eastwind]

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]

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]

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]

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.